Creare un editor di testo personalizzato basato sul web usando elementi "span": una cattiva idea?

Question

Ho un'idea per un'applicazione web per la quale richiedere il controllo completo della funzionalità degli editor di testo incorporati e gli editor di testo devono funzionare allo esattamente nello stesso in tutti i browser. La funzionalità standard contenteditable non è sufficiente per le mie esigenze in questa occasione.

Quindi ho sperimentato vari modi per implementare un editor di testo personalizzato. Il mio primo approccio è stato quello di rilevare i clic del mouse per l'inserimento del caret (anche se senza il caret visibile poiché non sembra essere un modo per ottenere ciò). Questo ha funzionato piuttosto bene, ma sfortunatamente non c'era modo di visualizzare il segno di omissione (noto anche come I-beam lampeggiante).

Ciò significa che anche il mio cerotto lampeggiante deve essere personalizzato. Posso solo pensare a due buoni modi per raggiungere questo obiettivo in modo compatibile con tutti i browser.

1. La prima opzione (e probabilmente migliore) sarebbe quella di implementare un motore di layout personalizzato in JavaScript, proprio come ha fatto Google con Google Docs.

2. La seconda soluzione (probabilmente molto più semplice) sarebbe quella di incapsulare ciascun carattere all'interno del proprio elemento <span> e quindi di consentire il posizionamento del falso carnet tra caratteri specifici. Ciò significa che ci sarà un sacco di elementi span, ma questo sicuramente realizzerà ciò di cui ho bisogno, sfruttando al contempo il motore di layout del browser. Un altro vantaggio di questo approccio è che non ho bisogno di fare affidamento su hacker di selezione del testo specifici del browser.

Quindi la mia domanda, l'opzione numero 2 è una pessima idea? Se è così, perché?

Answer 1

Prima di tutto, hai davvero bisogno di lavorare sul tuo editor? Ci sono Firepad e Etherpad con il loro montaggio collaborativo piuttosto interessante e forse più editor open source non basati su contenteditable. È davvero difficile creare un simile editor, quindi non ha senso sprecare tempo in esso.

Tuttavia, se si vuole veramente lavorare sulla propria soluzione ed è necessario esattamente lo stesso comportamento su tutti i browser, allora si è condannati;). Anche se eviterai lo contenteditable ci sono sicuramente altre cose che possono andare storte.

In ogni caso, la risposta:

1. prima opzione è molto difficile e richiede tempo all'inizio, ma ti dà molta più potenza rispetto alla seconda. Per esempio. avendo un motore di layout completamente personalizzato, sarete in grado di implementare le interruzioni di pagina senza attendere l'implementazione del CSS3 (su cui non potrete mai fare affidamento, perché lo corrisponde esattamente allo lo stesso comportamento su tutti i browser). In effetti, sarai in grado di ignorare la maggior parte delle differenze di rendering dei browser. Ma, a meno che tu non abbia una squadra di sviluppatori JS decenti e pochi mesi (almeno), non inizierei nemmeno a pensarci.

2. La seconda soluzione, riutilizzare DOM è più realistica. Prima dovevo eseguire alcuni test delle prestazioni, ma se avessi span per personaggio sarebbe stato facile scoprire dove posizionare il cursore dopo aver fatto clic con il mouse. Senza quello richiede un trucco ... Che non lo so.Puoi provare a controllare come Etherpad e Firepad (che usa Ace code editor) affrontano questo problema, ma il wrapping è la scelta più semplice e, almeno su browser decenti, non dovrebbe causare problemi di prestazioni, a meno che tu non voglia modificare documenti molto lunghi (ma allora puoi iniziare alcune ottimizzazioni).