Credo di aver riscontrato un potenziale problema durante l’utilizzo della funzionalità di indice generato automaticamente in DiscoTOC:
Quando si utilizzano intestazioni di vari livelli in lingue diverse dall’inglese, come il cinese, sembra che gli ID data-d-toc nell’indice generato automaticamente catturino solo cifre numeriche e lettere inglesi dalle intestazioni. Questa situazione può facilmente portare alla creazione di ID identici, causando di conseguenza collegamenti errati nella barra di scorrimento a destra.
Nell’immagine sopra, se i numeri seriali all’interno delle intestazioni sono entrambi 5, gli ID data-d-toc risultanti saranno entrambi toc-h2-5. Di conseguenza, ciò porterà due collegamenti distinti a dirigersi erroneamente verso la stessa sezione.
Tuttavia, modificando i numeri seriali in 1.5 e 2.5, gli ID data-d-toc saranno diversi (toc-h2-15 e toc-h2-25), garantendo efficacemente collegamenti accurati e appropriati.
Per garantire un collegamento accurato all’interno della barra di scorrimento, è consigliabile mantenere le intestazioni in inglese?
Inoltre, per lingue come il cinese, la soluzione più praticabile comporterebbe l’incorporazione di numeri seriali multilivello (ad esempio, 3.5, 3.6.5, 4.2.5.6) alle intestazioni?
Tuttavia, sebbene funzioni, non è perfetto, ma sono troppo pigro per modificare il codice.
Ovviamente una soluzione migliore è utilizzare base64 per generare data-d-toc e aggiungere un identificatore univoco per prevenire possibili titoli duplicati.
Al momento non ho l’autorità per apportare tali modifiche al forum della mia azienda, ma apprezzo comunque la tua risposta!
Inoltre, vorrei chiedere se il team ufficiale ha preso in considerazione l’inclusione del supporto per altre lingue non latine per quanto riguarda questo indice generato automaticamente nelle future versioni del componente DiscoTOC? @Lilly@awesomerobot
In verità, hanno preso in considerazione lingue non latine, utilizzando il metodo slugify(h.textContent). Sospetto che questa funzione slugify sia stata sviluppata in conformità con il metodo di generazione dello slug del forum. Quando non è in modalità ‘encode’, tendono a sorgere problemi, sebbene non abbia personalmente testato questa ipotesi.
In precedenza, quando utilizzavamo la versione ufficiale del componente del tema, il metodo di generazione dello slug del nostro forum era impostato su ‘none’, il che ha dato origine a problemi simili. Posso quindi suggerire di provare a modificare l’impostazione su ‘encode’?
In realtà hanno considerato le lingue non latine, utilizzando slugify(h.textContent), sospetto che questa funzione slugify sia stata generata in base al metodo di generazione dello slug del forum, quando non è encode sorgono problemi, ma non l’ho provato.
In precedenza, quando utilizzavamo la versione ufficiale del plugin, il metodo di generazione dello slug del nostro forum era impostato su none e si verificavano gli stessi problemi tuoi. Perché non provi a cambiarlo in encode.
Inoltre, considerando la velocità di correzione dei componenti da parte degli sviluppatori ufficiali… c’è un componente vicino a cui ho segnalato un problema l’anno scorso e non ho ancora ricevuto risposta, ti consiglio di richiedere l’uso della mia versione fork.
Ho provato a modificare questa impostazione, ma i problemi menzionati in precedenza persistono. L’ID data-d-toc può leggere solo numeri e lettere e ci sono ancora casi di ID duplicati della tabella dei contenuti. Suppongo che il punto cruciale sia altrove?
Chiederò al mio capo, grazie per la risposta~
Ho provato a modificare questa impostazione, ma i problemi menzionati in precedenza persistono. L’ID data-d-toc può leggere solo numeri e lettere e ci sono ancora casi di ID duplicati della tabella dei contenuti. Suppongo che il punto cruciale sia altrove?
