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

> ... 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.

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.

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

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...) 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-te...