3 ms·

Much of the complexity of contentEditable comes from using the same DOM nodes both as an output device to render a semantic data model, AND as an input device,

by jitl 4y ago

Much of the complexity of contentEditable comes from using the same DOM nodes both as an output device to render a semantic data model, AND as an input device, to interpret input-related events into changes to the semantic data model. If you can separate the two concerns, it would be much easier to eg accept CJK text and keep output looking correct, without breaking input.

catchclose8919 4y ago
100% this - but good luck fixing that, since the people who'd have expected contenteditable to work are the ones that want to unify input and output... so it's an intractable mess you basically want an UI for inputing and validating some schema-enforced JSON, but that's overwhelming and overkill for most users and more apps, so you script into existence a simplified version of that (aking to "everyone who doesn't learn lisp is cursed to reinvent it" or smth like that but for frontend devs).
- josephg 4y ago
  > 100% this - but good luck fixing that Its fixable. We just need to add a new, better designed rich text input element to the web.
- jitl 4y ago
  Plenty of editors do separate the input and output into different DOM nodes. Google Docs does this, as does Coda.