https://medium.com/content-uneditable/a-standard-for-rich-text-data-4b3a507af552
CKEditor 5 is a good example. It doesn't use the DOM anymore as its data model. Instead, a customized data representation totally defined and controlled with pure JavaScript appears. This new approach moves the "source code" of the text totally away from the browser. HTML disappears from the scene.
Note that I'm proposing here HTML as the data format to be used to save rich-text. I'm not in any way saying that such HTML is the way to then render the data. This means that it can really contain anything.
blog-post-a-standard-for-rich-text-data#register-the-user-intention1Ok, but now let's think about HTML as the way we want to save data. For that, we certainly don't need all of the above. We just want to register the user intention, leaving the rendering problem for later. In other words, what about having the following instead? blog-post-a-standard-for-rich-text-data#register-the-user-intention1
blog-post-a-standard-for-rich-text-data#capture-author-intent-in-data1With the above we're clearly saving, as part of our data, everything we need to know about the author intention. This is purely semantic and doesn't dictate the way we'll then present this data to our readers. blog-post-a-standard-for-rich-text-data#capture-author-intent-in-data1
If we want the so-called "power-users" to access source code, we may transform it to markdown, if you really want it. The benefit of it over RTE is dubious, though.