4 ms·

I wish these libraries didn't invent their own document model when we already have HTML. Just let me edit HTML, within constraints setup by a schema, and allow

I wish these libraries didn't invent their own document model when we already have HTML. Just let me edit HTML, within constraints setup by a schema, and allow extensibility of the document via HTML custom elements.

Ronsenshi 10y ago
You could allways use TinyMCE if simple HTML editing is all you need. Custom document model has its advantages in state change tracking, complex custom elements, unified rendering in different browsers (probably some other reasons too).
- spankalee 10y ago
  You can do all of that in HTML, especially complex custom elements that render the same in all browsers.
  - hatsix 10y ago
    but you can't do all of that in contenteditable... that's the point.
    - spankalee 10y ago
      I'm not taking about contenteditable, but the document model of the editor. Markup is much well suited to rich text because that's exactly what it was designed for.
JasonSage 10y ago
Then you have to handle cleverness around cursor highlighting, cross platform keyboard shortcuts, copying and pasting of rich text... why not start with a decent base of functionality with contenteditable inputs?
- spankalee 10y ago
  I don't understand what you're saying. Rendering the UI of the editor should be independent of rendering the content. contenteditable lends itself to an HTML document model anyway.
anilshanbhag 10y ago
As Rosenhai mentioned, you can use any 'old' editor like Summernote or TinyMCE if you just want to edit html. The problem comes when you want to sync changes to server / others in collaborative environment. Without a state, all you see is a dom element and then you have to generate the diff which is pretty hard due to browser nuances.
malloryerik 10y ago
Would it be possible to do live collaborative editing with a pure html-as-data model? One nice thing about Slate.js is that it leaves the door open to high-quality collaborative editing in React.
bastawhiz 10y ago
The markup that's generated by browsers in rich text areas is not standardized. Sort of a deal breaker for cross platform compatibility.
- Ralfp 10y ago
  Theres also good article from Medium's engineering titled "Why ContentEditable is terrible": https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480 https://medium.engineering/why-contenteditable-is-terrible-1...
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 ago
  Here'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 ago
  Who 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.
lobster_johnson 10y ago
In addition to what the other commenters said: HTML/DOM is a presentation-oriented document model. It's the "V" in MVC. It only works as the data model for something that is analogous to HTML. In particular, the moment you have content (data) that doesn't map 1:1 to DOM, you have an issue. For example, imagine I want to embed a "photo object". It's not just an image; it also renders the photo credit/copyright underneath. But that makes it a composite; internally, it's a photo ID, the dimensions, maybe some cropping info, plus the crediting metadata. So the internal data node no longer maps directly to the DOM. Internally, you want a single node, but in the DOM it would have to be multiple when rendered. Same goes for other composite embeds like videos, maps, forms, tables and so on. Editors are classic MVC: Regardless of whether the view is HTML, Cocoa, Qt, whatever the Windows UI API is these days -- you need to keep model decoupled from it.
tannhaeuser 10y ago
You might like SGML, the ISO-standardized markup meta-language on which HTML was built originally. In my project ([1]) I'm trying to bring it back to the web. [1]: http://sgmljs.net/blog/blog1701.html http://sgmljs.net/blog/blog1701.html
jschrf 10y ago
I'm with you on not reinventing DOM, but often you don't want your Document Model tied to DOM - despite nominal similarities - and Slate seems like a good example of how simple things can be made, even for rich document/app type things.

Ronsenshi 10y ago

You could allways use TinyMCE if simple HTML editing is all you need. Custom document model has its advantages in state change tracking, complex custom elements, unified rendering in different browsers (probably some other reasons too).

spankalee 10y ago
You can do all of that in HTML, especially complex custom elements that render the same in all browsers.
- hatsix 10y ago
  but you can't do all of that in contenteditable... that's the point.
  - spankalee 10y ago
    I'm not taking about contenteditable, but the document model of the editor. Markup is much well suited to rich text because that's exactly what it was designed for.

JasonSage 10y ago

Then you have to handle cleverness around cursor highlighting, cross platform keyboard shortcuts, copying and pasting of rich text... why not start with a decent base of functionality with contenteditable inputs?

spankalee 10y ago
I don't understand what you're saying. Rendering the UI of the editor should be independent of rendering the content. contenteditable lends itself to an HTML document model anyway.

anilshanbhag 10y ago

As Rosenhai mentioned, you can use any 'old' editor like Summernote or TinyMCE if you just want to edit html. The problem comes when you want to sync changes to server / others in collaborative environment. Without a state, all you see is a dom element and then you have to generate the diff which is pretty hard due to browser nuances.

malloryerik 10y ago

Would it be possible to do live collaborative editing with a pure html-as-data model? One nice thing about Slate.js is that it leaves the door open to high-quality collaborative editing in React.

bastawhiz 10y ago

The markup that's generated by browsers in rich text areas is not standardized. Sort of a deal breaker for cross platform compatibility.

Ralfp 10y ago
Theres also good article from Medium's engineering titled "Why ContentEditable is terrible": https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480 https://medium.engineering/why-contenteditable-is-terrible-1...

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 ago
Here'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 ago
Who 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.

lobster_johnson 10y ago

In addition to what the other commenters said: HTML/DOM is a presentation-oriented document model. It's the "V" in MVC. It only works as the data model for something that is analogous to HTML. In particular, the moment you have content (data) that doesn't map 1:1 to DOM, you have an issue. For example, imagine I want to embed a "photo object". It's not just an image; it also renders the photo credit/copyright underneath. But that makes it a composite; internally, it's a photo ID, the dimensions, maybe some cropping info, plus the crediting metadata. So the internal data node no longer maps directly to the DOM. Internally, you want a single node, but in the DOM it would have to be multiple when rendered. Same goes for other composite embeds like videos, maps, forms, tables and so on. Editors are classic MVC: Regardless of whether the view is HTML, Cocoa, Qt, whatever the Windows UI API is these days -- you need to keep model decoupled from it.

tannhaeuser 10y ago

You might like SGML, the ISO-standardized markup meta-language on which HTML was built originally. In my project ([1]) I'm trying to bring it back to the web. [1]: http://sgmljs.net/blog/blog1701.html http://sgmljs.net/blog/blog1701.html

jschrf 10y ago

I'm with you on not reinventing DOM, but often you don't want your Document Model tied to DOM - despite nominal similarities - and Slate seems like a good example of how simple things can be made, even for rich document/app type things.