[tkone]

nah, that’s not true at all. have a look at ‘rich-text’[1] which allows for transforms on metadata in a separate stream from the main content. it’s the same basic algo used for OT on plain text.

(i was the cto at a startup which used this to create a multi-user text editor with rich text support in 2015ish)

1: https://github.com/ottypes/rich-text

[Reinmar]

What's not true at all? That more powerful rich text editors need to rely on a tree structure?

[tkone]

yes. that is not true. you can build a rich text editor with simple ot. no tree necessary.

[Reinmar]

I agree. Yes, you can. Quill is the example here.

Actually, back in 2015 when we started prototyping CKEditor 5, we started with this approach as well. Our goal from the beginning was to combine real-time editing capabilities with an engine capable of storing and rendering complex rich-text structures (nested tables, complex nested lists, other rich widgets, etc.). We quickly realized that a linear structure is going to be a huge bottleneck. In the end, if you want to represent trees, storing them as a linear structure is counterproductive.

So, we went for a tree model. That got many things in the engine an order of magnitude harder (OT being one). But I choose to encapsulate this complexity in the model rather than make it leak to particular plugins.

In fact, from what I remember, https://github.com/quilljs/quill/issues/117 (e.g. https://github.com/quilljs/quill/issues/117#issuecomment-644...) is a good example of issues that we avoided.

I also talked to companies that built their platforms on top of Quill. One of them ended up gluing together countless Quill instances to power their editor and overcome the limitations of the linear data model but is now looking for a way to rebuild their editor from scratch due to the issues (performance, complexity, stability).

So, yes. You can implement a rich-text editor based on a linear model. But it has its immediate limitations that you need to take into consideration.