What's wrong with contentEditable
Problematic use cases in the wild
- Facebook implements rich editing via textarea and an overlayed element on top to visualize mentions
- Google plus has
contenteditable="plaintext-only"which seems to be completely JS-driven plain element
- Grammarly implements grammar-correcting-underlines via textarea + element on top (reasons: contenteditable is slow to render, no way to clean markup, hard to do proper selection/annotations)
- Quip has a hybrid editor (each paragraph is a contenteditable line; same with http://notion.so)
- Trix editor ignores contentEditable and maintains its own internal model (to avoid dealing with x-browser inconsistencies and complexities); same with ProseMirror
To make this simpler for sites, frameworks, and browsers, it makes sense to enable a new, simpler version of contentEditable that provides basic functionality only. For the sake of discussion, call it contentEditable='minimal'
Julie Parent breaking down potential
- Selections: Enable selections, perform cursor movement, scoping the boundaries on which the selection can operate.
- Input: Perform dom modifications, dispatch events, not limited to keyboard input, also includes IME, paste, drop, etc.
- Spell check: Enable spell check, modify the dom (or dispatch an event) when the user selects a replacement
- Formatting magic: bold when the user hits control + b, change directionality on Ctrl+LeftShift , etc.
Where do we draw the line with
cE=minimal? Only 1 or 1+2? Should
cE=minimal modify DOM? Opinions divided in two. Some say that DOM mutation is a can of worms that shouldn't be opened (instead allowing user to change it programmatically). Others say that cE=minimal will be useless without some sort of automatic text modification.
Light at the end of a tunnel?
What about this kind of tiered solution?
|contentEditable value||Fires events||Draws cursor||Mutates DOM||Formatting|