3 ms·
As other people mention, you can't really do this effectively via contenteditable, as user-intent (make that line bold) isn't uniformly transformed into consist
by pfooti 10y ago
As other people mention, you can't really do this effectively via contenteditable, as user-intent (make that line bold) isn't uniformly transformed into consistent DOM across browsers. Medium had a great post about all that a couple years back. They wouldn't go through the trouble of re-implementing contenteditable if it weren't absolutely necessary.
There are other problems with using contenteditable as well. Copy paste becomes very challenging (you're sanitizing an dom tree and actively snipping stuff you don't want, instead of converting only things you do want into the intermediate representation). As an exercise, look at what an older tinyMCE editbox actually looks like on the inside after you paste something from MSWord.
I have been using quill.js in production for a while now (since well before it was 1.0), and having an internal representation of the text state that gets turned into HTML on the fly as necessary is a good thing. Since rich text editors are by necessity generating user content, I feel less worried about exposing crappy content on the DOM to people who view what was edited - I have total control over what DOM nodes get emitted (the legacy system I replaced allowed for pasting raw HTML, so I'm a little sensitive to this).
Plus, having my content be in an intermediate JSON representation is quite useful. For example: It's trivially easy to wire the source of diffs from quill into a log server for playback, so you can handle concurrent editing without an impossible amount of work. Also, I actually transform the representation differently depending on context. In an email notification, an atMention custom element gets rendered as a boring href with some style, but internally to the site, an atMention gets some custom element stuff that allows a flyover to show the user. This would be a lot harder if I didn't have control over the json -> html transformation at render time.
- polm23 10y agoHere's that Medium post: Why Content Editable is Terrible https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480 https://medium.engineering/why-contenteditable-is-terrible-1...
- spankalee 10y agoWho said anything about contenteditable or not having control over the content? The editor can have complete control and still store the document in markup rather than JSON. HTML offers a number of advantages over a custom json-based document module, not the least of which is interop. You'd never want to store Skates data model in a database in case you switch editors.
- pfooti 10y agoI agree that HTML format has some strengths, but if you're working with data in javascript, there's a lot of strengths to a json format as well. Personally, I do store json data in my database (in a jsonb postgres column, which gives me some query capabilities that aren't necessarily available operating on html strings in the database). I also agree, though, that this leads to some degree of lock-in. You'd have to write a transformer to convert to your new framework, but that's not particularly hard. Ultimately, though, the way I think about it is: react, angular, ember, vue all work by converting a JSON representation of state into a dom tree. So, an editor doesn't really need to be much different, as long as render times are fast, having an internal representation that's projected on to the DOM is a pretty common pattern.
- lukasbuenger 10y agoHTML or any other markup language for that matter is very hard to translate into a well-defined and predictable data structure. When working with content editors, this, to me at least, is a hard requirement.