| Thanks! I totally agree with you, those were some of the other limitations I ran into and tried to solve for. > If you can have nested blocks, do you really even need marks? Are they just there for convenience? Interesting question! It depends slightly on your use case, but I think for most of the "rich text editing" use cases, you'll probably want them. They're beneficial in that they have separate semantics to inline nodes in the tree, since they aren't nested. Such that you can apply them in any order, and the JSON data structure is the same. This is useful because you don't have to worry about ordering when doing things like bold(italic(strikethrough(comment(TEXT)))). Which is usually simpler for users to understand, and simpler to work with in code anyways. The inline nodes are only really useful for what you'd model in HTML as `display: inline-block`, for things that aren't really running "text" but can appear in the middle of the document, like inline images, latex, etc. But if you're able to avoid inline nodes altogether, it's easiest to model things as blocks and marks. This has me thinking about whether it's possible to get rid of "inline" nodes though, that's interesting. |