2 ms·
I suspect the best way to make rich text editing work across browsers is to do what the current google docs editor does: Drop contentEditable and just implement
by dunham 13y ago
I suspect the best way to make rich text editing work across browsers is to do what the current google docs editor does: Drop contentEditable and just implement your own editor in javascript. Read key and mouse events and manipulate the DOM.
It's a bit more work up front, but possibly less work than trying to get four different implementations of contentEditable to behave the way you want. And this way you own the editing logic.
- sunir 13y agoDo you know any good libraries that do this? I tried building one a long time ago. The hard parts are mouse events (ie moving the caret based on a pixel coordinate) and pasting. Google docs solves the mouse event problem by rendering every glyph offscreen and measuring it's bounding box. That is intensive and difficult if your font is bidi or changes by context (eg Arabic, accents). I tried wrapping every glyph in a span but it wiped out the available RAM. That may not be a problem anymore in 2014.
- dunham 13y agoHonestly, I haven't looked into it. The bounding box thing sounds messy. But on chrome, firefox, and probably safari, it appears that you can call document.getSelection() in a click handler, and the returned object will be an appropriate Caret selection with offset and node. I recall that the selection object in older versions of IE do not offer the character offset, so you have to copy the selection and move it one character at a time until you get to the beginning of the text node. IE9 and above appear to have modern selection objects (according the MS docs). I don't know if they're updated onclick.