I was thinking about this during Timo's presentation and to be quite honest; there's not a single solution to this issue without giving some form of Trade-off. DraftJS or Medium-like Editor may address many issues most users are frowned upon. However, what are we willing to trade-off for usability, simplicity, security, adaptivity, flexibility, superpowers, performance, elegant design and feature-rich editing experience? TinyMCE comes tonnes of features, performance optimisation and security audits, which can be disabled or toned down. However, as stated by not just Plone users, but almost everyone, TinyMCE is ugly and changes the structure of a standardised content.
Luckily for us, Plone is flexible to set a default editor and switch between editors. This means that we can integrate DraftJS, Medium-like Editor or any feasible editor while keeping TinyMCE for power-hungry users at the cost of maintaining various add-ons and decoupling TinyMCE from the heart of Plone.
By having these editors as add-ons, we will be able to:
- allow site managers to set a default editor based on the audience.
- having multiple editors, which a site-admin or manager can temporarily switch to if they need superpowers. For instance, TinyMCE allows you to edit the HTML of the content. However, all editors must use the same methods for rendering content
- ease the mind of content structuring since Medium-like editor and DraftJS don't impact the style, design and structure of the rendered content as much as the annoying TinyMCE editor does.
.... ok... going to cut this short....
Other things to note:
- buildout should provide a means to "do not install TinyMCE addon" especially when site users will be using another editor
- a couple of weeks ago, I thought it could be a GSoC project, but I think its best that developers with experience of the problem and Plone work on these addons