Elaboratore di testi Javascript/editor (o, architettura di Google Docs)

Ho pensato che sarebbe stato interessante girare il mio editor di testo alla Google Docs, puramente per curiosità ovviamente (niente a che fare con il reinventare la ruota). Mi stavo chiedendo come applicazioni come Docs e Zoho Writer possano ottenere layout avanzati come separare il testo su pagine diverse, o tenere intestazioni con i loro contenuti, sapete, gli editor di cose come TinyMCE o nicedit non lo faranno. Sono consapevole dell'uso di designMode e contenteditable e ho sentito persone che usano la tela, ma c'è un modo migliore? Come gestiscono le suite di desktop office come MS o LibreOffice? Soprattutto suddividendo il contenuto in pagine discrete mentre vengono modificate?Elaboratore di testi Javascript/editor (o, architettura di Google Docs)

Nota a margine, qualcuno è a conoscenza di come funziona il nuovo Google Docs? Non sembra usare contenteditable (Zoho usa designMode), né canvas. Da quello che ho trovato, è solo una gerarchia molto profonda di <div> s.

fonte

2012-01-06 Art

io non sarei sorpreso se solo catturano l'input da tastiera/mouse con JavaScript e cambiare il DOM a seconda dei casi. Detto questo, suppongo non abbia nulla a sostenerlo e sono troppo pigro per esaminarlo. –

Google non smette mai di stupirmi con i modi creativi con cui hanno dei tag di nidificazione per realizzare tutte le loro animazioni ed editori. –

Tikkon, ci ho pensato. Sembra una tale seccatura continuare a catturare tutte le chiavi alfanumeriche, oltre ai modificatori. Mi chiedo se ciò possa comportare qualsiasi tipo di penalizzazione delle prestazioni. Una nota a margine, dopo aver scansionato il DOM, sospetto che il segno di omissione in Docs sia in realtà un elemento DOM intermittente. Mente bruciata, qualcuno? – Art

tua 'domanda' è un po 'largo, ma cercherò di aiutarti un po':

Google Documenti utilizza un nascosta iframe (non display:none, è solo che l'utente non può in realtà vedere it) con un corpo con contenuto modificabile (.docs-texteventtarget-iframe); quando vedi il cursore lampeggiante significa che il corpo modificabile è focalizzato e tutto ciò che scrivi viene inserito nel DOM (dopo aver disinfettato caratteri HTML speciali)

Google Docs, come ho detto, sta usando la modifica DOM (non tela o SVG); anche il segno di omissione è un po 'div lampeggiante.

TinyMCE usa una tecnica simile, ma con un campo di input (invece di un corpo contenuto modificabile)

fonte

2012-01-06 03:42:23

Punto preso - Ho chiarito la domanda. Questa è una soluzione piuttosto elegante - suppongo che i tasti premuti vengano catturati e basati su una macchina a stati finiti, vengano intraprese azioni come l'applicazione di formati o l'inserimento di caratteri? – Art

L'evento non è effettivamente acquisito in senso tecnico, tutto è scritto sul corpo (o inserito in TinyMCE) e immediatamente dopo che il carattere è stato copiato nel "documento" e il corpo/input cancellato. Questo perché catturare l'evento porta a incongruenze nell'interpretazione dei keycode (diversi browser/setup). –

Perché non si dovrebbe piuttosto modificare il corpo stesso, se gli eventi non vengono catturati in quel modo? – Art

Elaboratore di testi Javascript/editor (o, architettura di Google Docs)

risposta

Problemi correlati