3 ms·

Is the output just a giant blob of HTML? If so, I don't see what this does to solve what I see as the main problem of WYSIWYG editors... a terrible end-format f

Is the output just a giant blob of HTML? If so, I don't see what this does to solve what I see as the main problem of WYSIWYG editors... a terrible end-format for stored content. I got my hopes up when reading the intro that we would see a more structured output (not just the underlying in-browser data model). I would love to see a WYSIWYG output a JSON structure with markdown content. Not to minimize what appears to be a massive and successful effort! I just feel like HTML is a completely inflexible and rigid way to save content.

justinator 9y ago
The demo video at the bottom of the page shows that it can output to Markdown easily.
- Reinmar 9y ago
  I could never understand why people favour Markdown over HTML. Markdown is the worst idea when it comes to storing data. It's not standardised so there are dozens of incompatible flavours and incompatible Markdown -> HTML and HTML -> Markdown converters. Introducing Markdown to your app will eventually bring troubles but developers rarely notice this cause all seems to work initially when they test the simplest cases. So, why did we create a Markdown data processor for CKEditor 5? (You can find a demo of it here: https://docs.ckeditor.com/ckeditor5/latest/features/markdown.html https://docs.ckeditor.com/ckeditor5/latest/features/markdown...) It was just to showcase that you can actually do that. But I'd never recommend it to anyone. HTML as a format is standardised and stable and there are even more tools to process it. PS. There's the CommonMark standard, but it was created too late and its adoption is low. PPS. We actually wrote an article called "A Standard for Rich-Text Data" – you can read it here: https://medium.com/content-uneditable/a-standard-for-rich-text-data-4b3a507af552 https://medium.com/content-uneditable/a-standard-for-rich-te...
dotancohen 9y ago
> ... the main problem of WYSIWYG editors... a terrible end-format for stored content. In many cases having the editor store HTML internally is the best solution, especially if the output will eventually be HTML anyway. Think of a Wordpress post submission page, or a website comment page.
- 11235813213455 9y ago
  it's still bad, for consistency you want to reuse classes, etc.. webflow CMS does it right
scofalik 9y ago
The idea behind storing and loading the data is, in short, this: HTML is the most popular format and it is the default when it comes to publishing web content. Most people want HTML data. However, it is understood that in the modern web era, there is a need for more. In CKE5 there is a "data processor" unit. The data processor is responsible for taking DOM (generated from editor's data model) and converting it to the output you want. The default processor is HTML processor, but you could hook there any processor that can convert DOM structure to anything you want. You can use already existing libraries or write your own if you need something really custom. To sum up, the road from editor's model to the output data is this: custom model -> view (DOM-like structure) -> DOM -> Data processor -> stringified data
dhoulb 9y ago
I agree HTML in its entirity is not a great way to store data, but a SUBSET of HTML is often pretty efficient. Storing a paragraph where words might be bold or italic — a string of HTML’s pretty great for that, compared to some convoluted JSON thing, and can pretty easily be converted to other formats if needed. Even a list of paragraphs with mixed occasional lists etc. HTML is still pretty friendly at that point. I think where HTML strings outlive their usefulness is when you start mixing in <div> <iframe> <script>, nested sections. The string starts becoming unpredictable at that point and you have to worry about side effects. But for use cases where you want a small whitelisted set of tags, I think HTML is great.

justinator 9y ago

The demo video at the bottom of the page shows that it can output to Markdown easily.

Reinmar 9y ago
I could never understand why people favour Markdown over HTML. Markdown is the worst idea when it comes to storing data. It's not standardised so there are dozens of incompatible flavours and incompatible Markdown -> HTML and HTML -> Markdown converters. Introducing Markdown to your app will eventually bring troubles but developers rarely notice this cause all seems to work initially when they test the simplest cases. So, why did we create a Markdown data processor for CKEditor 5? (You can find a demo of it here: https://docs.ckeditor.com/ckeditor5/latest/features/markdown.html https://docs.ckeditor.com/ckeditor5/latest/features/markdown...) It was just to showcase that you can actually do that. But I'd never recommend it to anyone. HTML as a format is standardised and stable and there are even more tools to process it. PS. There's the CommonMark standard, but it was created too late and its adoption is low. PPS. We actually wrote an article called "A Standard for Rich-Text Data" – you can read it here: https://medium.com/content-uneditable/a-standard-for-rich-text-data-4b3a507af552 https://medium.com/content-uneditable/a-standard-for-rich-te...

dotancohen 9y ago

> ... the main problem of WYSIWYG editors... a terrible end-format for stored content. In many cases having the editor store HTML internally is the best solution, especially if the output will eventually be HTML anyway. Think of a Wordpress post submission page, or a website comment page.

11235813213455 9y ago
it's still bad, for consistency you want to reuse classes, etc.. webflow CMS does it right

scofalik 9y ago

The idea behind storing and loading the data is, in short, this: HTML is the most popular format and it is the default when it comes to publishing web content. Most people want HTML data. However, it is understood that in the modern web era, there is a need for more. In CKE5 there is a "data processor" unit. The data processor is responsible for taking DOM (generated from editor's data model) and converting it to the output you want. The default processor is HTML processor, but you could hook there any processor that can convert DOM structure to anything you want. You can use already existing libraries or write your own if you need something really custom. To sum up, the road from editor's model to the output data is this: custom model -> view (DOM-like structure) -> DOM -> Data processor -> stringified data

dhoulb 9y ago

I agree HTML in its entirity is not a great way to store data, but a SUBSET of HTML is often pretty efficient. Storing a paragraph where words might be bold or italic — a string of HTML’s pretty great for that, compared to some convoluted JSON thing, and can pretty easily be converted to other formats if needed. Even a list of paragraphs with mixed occasional lists etc. HTML is still pretty friendly at that point. I think where HTML strings outlive their usefulness is when you start mixing in <div> <iframe> <script>, nested sections. The string starts becoming unpredictable at that point and you have to worry about side effects. But for use cases where you want a small whitelisted set of tags, I think HTML is great.