Every browser uses different markup to represent contents of contenteditable. One browser uses div for text and splits it into two when enter is pressed, other browser inserts <br/>, next one has paragraph, etc. ect.

JSON is not here for resemblance, but for normalization. You force single presentation of things from start, and when user presses enter (or other text composition event happens) you prevent default action, update document model (JSON) and then update the HTML.

This approach is much more sane and predictable than trying to trust browser's HTML.

Still, that does not mean it cannot output HTML. CKEditor 5 implements a custom data model, works in the way you described (cancel native actions or extracts stuff from it, apply those changes to its data model and re-renders the DOM if needed), but it still outputs HTML. Thanks to that you don't need a processor to use that content on your page. Plus, there are cases where converting a custom data model to HTML is actually a tricky job (e.g. inline formatting) and even Editor.js chose HTML for those.

JSON is quite nice compared to HTML, in my view. It's less verbose. Also, I like the flatness of Editor.js's data model.

Being JSON makes it easier to render into other formats, too.

In all cases you override the default action and determine what content to generate. The format (JSON or HTML) is an entirely separate discussion.

I think the idea is platform agnosticism. What if you're serving to a client that doesn't understand html? You'll need to interpret it somehow...

Text objects are apparently still HTML, I.e. HTML parsing is still required to understand the input.

Totally agree. In fact, they even used HTML inside the "text" property so, in fact, they mix JSON with HTML which doesn't seem to make a lot of sense.

You can have a nice structured HTML and it will be as portable, as interoperable (if not more) as that JSON.

Another take on this (by my colleague from CKEditor team): https://medium.com/content-uneditable/a-standard-for-rich-te...