Hey Dmitri,
great that you are putting thought into this definitely exciting topic 
tl;dr: I’d go for variant 3 plus the fourth option, outlined below.
Going Meta
Before delving into the topic, I’d first like to discuss about Content and Document nodes on a “Meta” level:
To me, besides all the technical detail differences (e.g. Document has a URL, Content has not), there is one main “philosophical” difference between the two for me: Document nodes make sense on their own, e.g. they represent an own distict entity which has an external identity, usually has a meaningful external identifier (=name), and a Document (=a Document Node and corresponding content) is a unit of sense. That means you usually can look at a Document without knowing much context, and you will understand a certain information.
On the contrary, Content is a different beast: It is part of a larger Document, and it conveys a certain “information snippet” (like a sentence, a paragraph, an image, or a longer text). However, a single Content node on its own, e.g. without its surrounding Content, is only conveying a smaller snippet of information. That is, to make sense of it, you often need surrounding context (=the nodes before and after).
Of course, this is not meant black-or-white: Some parts of Content, especially those types containing nested-content, often convey meaningful information on its own. The text above basically describes the ends of the spectrum to me.
Consequences of this “Meta” difference between Documents and Content
Because of the differences outlined above, the following behavior is adjusted in Neos for Document and Content, respectively:
- the unit the editor sees at once is a single Document (usually)
- Documents have a distinct URI, Content has not.
- -> You can link to Documents, but not to Content
- (Content Dimensions) When translating, you usually do it on a document-by-document basis.
- -> for Documents we have a very rigid connection between the different variants of a Document, i.e. you want to link to the other-language variants of a page.
- -> we move the different variants of a Document node in all dimensions at once, because we believe the entity should always be locatable at the same position across all dimensions. (sidenote: this will be made more flexible lateron; but I believe still it is a useful default)
- -> for Content, you can more freely restructure it; you might even sometimes have no 1:1 mapping of content on different dimensions. Example: For some RTL-languages, you might want to place content in different containers, in a different ordering; or you might want to not show certain images in a certain language.
- -> basically, it’s the editor’s responsibility to convey the same information on a Document in different dimensions; by using any Content nodes he wants/needs.
Why do we need Content nodes at all?
The above statements might sound like for Content, it would be enough to store everything in a large “Blob” (e.g. how Gutenberg/Wordpress does it). It turns out this is not the case, because:
- we can use constraints to restrict which kinds of content are allowed at which position
- often, there exist some “grouping” content nodes, like stages, semantic sections, highlight blocks, … - which convey a content block which is sufficiently able to stand on its own.
-> so by having (tree-structured) Content nodes as well, we allow for a big amount of flexibility to allow to cater to all kinds of use cases.
Back to CKEditor integration
Now, mapping the argumentation above to the 3 ways proposed by @dimaip, they score as following for me:
- Rather “un-pragmatic”. We are enforcing lots of “content structure” without any semantical meaning. (that’s why I put content structure in quotes: It looks as if the content is structured; but it does not convey semantical meaning)
- similar drawback as 1: it looks structured, but in fact it’s just a mapping of the paragraphs and headlines we have (at the lowest level). We do not really have semantical meaning here IMHO.
- this solution assumes that always where you need a special content (e.g. insert an image, …), something semantically relevant takes place. This assumption is sometimes right, sometimes wrong I think. In many cases, this is a good indicator for some semantic “belonging”, but sometimes it is just done for visual/aesthetic reasons. Because of this, for me this is the best solution of the proposed 3 solutions, because it balances pragmatism and well-structuredness.
Besides mapping the “philosophical argumentation” to the 3 proposed solutions, I see the following further properties:
- We would loose a common undo/redo stack inside a bigger chunk of text - and people are accustomed to it. Same for Copy/Paste of longer texts, which would be way harder.
- As the rendering of Nodes is controlled by Fusion, it would be kinda hard to map this to the CKEditor world - essentially, CKEditor would need to know how a certain Node is rendered at a certain location by Fusion. However, this is totally hard because of the flexibility of Fusion (conditional renderings, …)
Further Proposal: Inline Nodes in Text-Properties
To me, the main problem with solution 3. is that purely for getting a certain aesthetic, I am forced to use a certain Node structure. Further, creating things like e.g. inline images, or having a long text with references to other entities (which are not plain links, but more “widget-like”), gets more and more complicated. Examples could be displaying Stock Market indices next to a company name; or birthdates next to person names.
So that’s what I would want to solve, by combining how we currently do inline links with nested Nodes:
- In an inline editable text block, one could insert a nested Node inline at the cursor position. The system would insert markup like .
- At rendering time, the markup would be converted to a rendering of the specified Node UUID.
- These nodes are child nodes of the current Node; they are created only via CKEditor itself and purely managed in CKEditor. They are not creatable outside of CKEditor. When you remove them in CKEditor, they must be deleted behind the scenes.
- These nodes always exist in the same Dimension as its parent node (e.g. the node where they belong to).
- In CKEditor, they could be represented by what I believe is called Blocks; i.e. non-editable content areas.
Closing thoughts
This has been a rather long post now 
- Hope you don’t mind and I was able to somehow express my thoughts. Looking forward to the discussion 
All the best,
Sebastian
