11

I thought it would be interesting to roll my own text editor a la Google Docs, purely for curiosity of course (nothing to do with reinventing the wheel). I've been wondering how applications like Docs and Zoho Writer can get advanced layout like separating text on different pages, or keeping headings together with their content, you know, things editors like TinyMCE or nicedit won't do. I am aware of using designMode and contenteditable, and I've heard people using canvas, but is there a better way? How do desktop office suites like MS or LibreOffice manage that? Especially splitting the content into discrete pages while they are being edited?

On a side note, anyone aware of how the new Google Docs works? It doesn't seem to use contenteditable (Zoho uses designMode), nor canvas. From what I found, it's only a very deep hierarchy of <div>s.

  • 1
    I wouldn't be surprised if they just catch keyboard/mouse input with JavaScript and change the DOM as appropriate. That said, I'm guessing with nothing to back me up and I'm too lazy to look into it. – Tikhon Jelvis Jan 06 '12 at 01:55
  • 2
    Google never cease to amaze me with the creative ways they have of nesting tags to make all their animations and editors. – Chris Laplante Jan 06 '12 at 01:55
  • 1
    Tikkon, I thought of that. Seems such a huge bother to go through capturing every alphanumeric key, plus modifiers. I wonder if that would incur any kind of performance penalty. On a side note, after crawling the DOM I do suspect that the caret in Docs is actually a blinking DOM element. Mind blown, anyone? –  Jan 06 '12 at 01:57
  • I could have sworn that I've seen Facebook do something similar in the past. Currently, they just use a textarea dressed up with JavaScript. But, I do remember at one point noticing them using a `div` tag as a custom editor. – Chris Laplante Jan 06 '12 at 02:13

1 Answers1

3

Your 'question' is a little wide, but I will try to help you out a little bit:

Google Docs is using a hidden iframe (not display:none, is just that the user can't actually see it) with a body with content editable (.docs-texteventtarget-iframe); when you see the caret blinking it means that the editable body is focused and everything you write there gets inserted in the DOM (after sanitizing special HTML characters)

Google Docs, like I said, is using DOM modification (not canvas or svg); even the caret is a little div blinking.

TinyMCE uses a similar technique but with an input field (instead of a content-editable body)

alex
  • 479,566
  • 201
  • 878
  • 984
Ivan Castellanos
  • 8,041
  • 1
  • 47
  • 42
  • Point taken - I clarified the question. That's quite an elegant solution - I suppose keypresses are captured and based on a finite state machine, actions are taken such as applying formats or inserting characters? –  Jan 06 '12 at 04:05
  • The event is not actually captured in the technical sense, everything is written on the body (or input in TinyMCE) and immediately after the character is copied to the "document" and the body/input cleared. That is because capturing the event leads to inconsistencies in the interpretation of the keycodes (different browsers/setups). – Ivan Castellanos Jan 06 '12 at 04:16
  • Why would one not rather edit the body itself, if the events aren't being captured that way? –  Jan 06 '12 at 15:26
  • Because JS is a mess; in most browsers you can't even detect if is uppercase or not until is actually written. The another problem is pasting, you cannot access the clipboard in Chrome and many other browsers until the user actually presses ctrl+V. And another hundreds of problems make this the very best solution. – Ivan Castellanos Oct 31 '13 at 21:15