@dimaip I’d REALLY like to use CKEditor, as we did lots of discussions with the CKEditor guys and I am sure they are handling lots of edge cases… And we have “premium support” by them.
I don’t care if the editor is on NPM or not, we should not limit ourselves by “whether it uses the hip package management” or not
We could make the editor implementation pluggable; BUT I’m 100% for making CKEditor the default, which is shipped with Neos. In my opinion, nothing has changed since we last evaluated the editors; so this decision is still valid…
For Neos, I think there are two possible directions which might be required/wished by users.
Either a very stripped down RTE, creating many structural node types (I know @dimaip does this, @wbehncke and @bwaidelich to name a few).
or a more full-blown editing experience where you’d f.e. want tables, bullet lists, different header stylings.
I see use cases for both and I’d like Neos as a tool to cater for both use cases, as I simply don’t know which of both cases will be the one accepted by the market in the longer term. (Might also be dependent on different market segments).
I feel that CKEditor, while “historically” being on the “full-blown-side”, is a great fit for the “stipped-down-RTE” as well, because in a nutshell:
you can excellently control which markup is allowed in the RTE
we can run the RTE completely headless, with our own UI powering it; as it has a good API. Frederico demoed this to us.
Still, if we need advanced features like tables, … it will “just work” without breaking in subtle ways.
Additionally, CKeditor 5 will be a great step into a direction which will work extremely well for us. I expect that we’ll basically just use the CKEditor Core library, and integrate it with our custom UI.
Furthermore, there are some “soft facts”, mainly that they’ll support us directly, their core devs even hang out in #project-ckeditor in our slack
Still, I think it totally makes sense to make the editor pluggable; but to me the default choice of CKEditor is quite important because of the reasons explained in this thread.
tl;dr: Use CKeditor as default editor implementation shipped with Neos, but make it switchable.
Hey Sebastian!
Just a small comment: what use case will the market accept depends a lot on which use case we push with Neos as the recommended use case. Aiming for COP and structured editing, we should try to show users the benefits of keeping structured data, and not just a big blob of HTML. Things like the default editor config will contribute to it.
For example I was really mad at first, that Aloha didn’t support assigning custom classes, but in the end it pushed me to better solution with which I’m still happy: use nodetypes for custom block level elements.
But in the long run, yes, I agree with decision: support both use case, support switchable RTEs, BUT make the default configuration align with the Neos vision and educate users to appreciate COP more.
Full ack concerning the default config! It’s just that I think that when we bet on some user behavior assumptions, it limits the risk if we take into account that we might be wrong in certain areas or use-cases
I think that many users of Neos don’t think like we programmers do and just want an editing experience like they have with their default text editor (most common: Microsoft Word).
So having the ability to make that possible would surely help Neos to spread further!
Fully agree with Sebastian here and Dmitri regarding providing stripped down defaults. Same discussion over again.
However supporting switchable RTEs requires way more work than implementing one RTE supporting different use cases, which is exactly what CKEditor does. In terms of consistent custom UI, custom plugins (linking etc.). This is the reason I keep advising against it, we tried it already (Create.js) and it never happened due to lack of interest. Although if there’s anyone willing to put in that extra effort of supporting multiple RTEs, I wouldn’t block it. But I don’t see much benefit of it so wouldn’t make it a responsibility of the core team.
Also other structured editing tools like Contentful and GatherContent provide full RTEs for their BLOB content, which proves that there’s certainly a need for that even in structured content scenarios.
I’d advise against switchable RTEs if it requires much more effort.
For the time being, an editor supporting most of the features one would like to have would suffice. Having an extendable editor (like CKEditor is) would be even greater!
I’ve been there with Frederico at the Code Sprint and his demo was pretty convincing. However I’m not deeply enough into that topic (and other alternatives) to judge, so just one comment regarding:
I might state the obvious, but IMO the fully fledged RTE is just the compromise for a lack of usable alternatives.
If we could get to an editing experience of a regular word processor combined with the power of proper semantics – man that would be a USP.
Concretely it should be possible to make it really easy for the editor to actually let the system know what he’s writing about. E.g. a list of employee names could be a bullet list within a RTE blob - or it’s a collection of employee nodes. But the editor won’t (always) go the extra way to go through the “new node” wizard… So there should be an easier way for those “nested structures”.
) to the development ;).