3 ms·

Can somebody give any use case that make this project or draft.js interesting compared to all the other WYSIWYG editors available (tinyMCE, CKEditor and so on..

Can somebody give any use case that make this project or draft.js interesting compared to all the other WYSIWYG editors available (tinyMCE, CKEditor and so on...)? Especially since the generated HTML of the editor is very verbose and doesn't respect semantic (header1 isn't translate as h1 but a div with a super long id. Why?) And what is so terrible about contentEditable? I spent a few minutes with it a few month ago and it felt great (and works on old version of IE), just lacking some library on top of it to give the end user a way to fully control everything.

HillRat 11y ago
ContentEditable is an absolute nightmare across browsers if you want to normalize your content in any way -- since there's no standard for what the generated HTML is supposed to be, every browser implements it differently (and sometimes very unusually). Couple that to the fact that you can't control what the user is doing (at least not without intercepting events where possible) and you have a feature that lands somewhere between worthless and actively malicious.
- mickaelkerjean 11y ago
  In the same way as highjacking the scrollbar, WYSIWYG editors have always feel like a hack to support end user needs without technical background. The idea of being able to seamlessly edit a website, create pages that respect semantic that even my grand ma could maintain is quite compelling to me. Many of those editors tends to produce bad looking HTML code that might be fine for today but will become an headache to migrate to any other platform or will become an headache when somebody decide they want to change the color of all their link as their crappy editors produce inline styling .... Anyway we might not have a one size fit all solution but WYSIWYG isn't a perfect solution either.
juretriglav 11y ago
How about built in support for collaborative editing: https://twitter.com/juretriglav/status/710191077102395392 https://twitter.com/juretriglav/status/710191077102395392 (they're just now working on this). The internal document model supports OT, and the collaborative feature is based on the Google Wave model. In the very near future there will also be NLM JATS XML support (a standard format in science). To address the verbosity: if you're looking at the output HTML, you're looking at the wrong place. That's just a rendering of the internal model, which is very succinct and semantic indeed, e.g. in XML: https://github.com/substance/lens/blob/d18d2c6353db8d97649b9257347d4762512c616f/data/small-example.xml https://github.com/substance/lens/blob/d18d2c6353db8d97649b9...
_mql 11y ago
Hi Mickael! Each content type consists of the following pieces: - Node (model) [1] - Component (visual representation) [2] - Converter (optional, used to map from and to XML/HTML) [3] The verbose output for heading1 you see is just the DOM projection of the data, which is custom and can be specified in the Component implementation [2]. Often you need to add extra markup and interactive elements, so that's why for Substance content (data) is not rendered 1:1 but through a custom renderer component. Please have a look at the examples [4], which includes minimal but functional implementations using most of the available concepts. [1] https://github.com/substance/substance/blob/master/packages/heading/Heading.js https://github.com/substance/substance/blob/master/packages/... [2] https://github.com/substance/substance/blob/master/packages/heading/HeadingComponent.js https://github.com/substance/substance/blob/master/packages/... [3] https://github.com/substance/substance/blob/master/packages/heading/HeadingHTMLConverter.js https://github.com/substance/substance/blob/master/packages/... [4] https://github.com/substance/examples#substance-examples https://github.com/substance/examples#substance-examples

HillRat 11y ago

ContentEditable is an absolute nightmare across browsers if you want to normalize your content in any way -- since there's no standard for what the generated HTML is supposed to be, every browser implements it differently (and sometimes very unusually). Couple that to the fact that you can't control what the user is doing (at least not without intercepting events where possible) and you have a feature that lands somewhere between worthless and actively malicious.

mickaelkerjean 11y ago
In the same way as highjacking the scrollbar, WYSIWYG editors have always feel like a hack to support end user needs without technical background. The idea of being able to seamlessly edit a website, create pages that respect semantic that even my grand ma could maintain is quite compelling to me. Many of those editors tends to produce bad looking HTML code that might be fine for today but will become an headache to migrate to any other platform or will become an headache when somebody decide they want to change the color of all their link as their crappy editors produce inline styling .... Anyway we might not have a one size fit all solution but WYSIWYG isn't a perfect solution either.

juretriglav 11y ago

How about built in support for collaborative editing: https://twitter.com/juretriglav/status/710191077102395392 https://twitter.com/juretriglav/status/710191077102395392 (they're just now working on this). The internal document model supports OT, and the collaborative feature is based on the Google Wave model. In the very near future there will also be NLM JATS XML support (a standard format in science). To address the verbosity: if you're looking at the output HTML, you're looking at the wrong place. That's just a rendering of the internal model, which is very succinct and semantic indeed, e.g. in XML: https://github.com/substance/lens/blob/d18d2c6353db8d97649b9257347d4762512c616f/data/small-example.xml https://github.com/substance/lens/blob/d18d2c6353db8d97649b9...

_mql 11y ago

Hi Mickael! Each content type consists of the following pieces: - Node (model) [1] - Component (visual representation) [2] - Converter (optional, used to map from and to XML/HTML) [3] The verbose output for heading1 you see is just the DOM projection of the data, which is custom and can be specified in the Component implementation [2]. Often you need to add extra markup and interactive elements, so that's why for Substance content (data) is not rendered 1:1 but through a custom renderer component. Please have a look at the examples [4], which includes minimal but functional implementations using most of the available concepts. [1] https://github.com/substance/substance/blob/master/packages/heading/Heading.js https://github.com/substance/substance/blob/master/packages/... [2] https://github.com/substance/substance/blob/master/packages/heading/HeadingComponent.js https://github.com/substance/substance/blob/master/packages/... [3] https://github.com/substance/substance/blob/master/packages/heading/HeadingHTMLConverter.js https://github.com/substance/substance/blob/master/packages/... [4] https://github.com/substance/examples#substance-examples https://github.com/substance/examples#substance-examples