[kiwidrew]

Both of those editors rely on the contentEditable support of the browser to power the actual editing, and browsers have traditionally done a very poor job at producing valid HTML. They make attempts at "post-validation" and "attribute scrubbing", but these are at best makeup on a gorilla. I certainly wouldn't call their solutions elegant.

Having worked on numerous content management systems in the past, one of our biggest issues was trying to "lock down" the WYSIWYG editor so as to minimize the chances that clients could inadvertently break the layout when editing. It was a huge pain point for us, and I lost count of the number of times I had to go in and fix broken pages.

I'm very glad to see that the state of the art in HTML editing is moving forward, and it's well past time for CKEditor and TinyMCE to be put to pasture, IMHO.

[silvestrov]

Same problem here: the one feature that all these editors lack is the ability to restrict what kind of formatting that the users can create.

In a system I've created for a client, some users are allowed to use e.g. bold and italic, but most users aren't (because they would go overboard and make every other word bold). Post-scrubbing the edited html often breaks the editing experience, and browsers have lot's of bugs in contenteditable.

[draftkraft]

Hi all, we try to address this issues (bugs of the browsers and functionally to restrict to defined formatting) with Aloha Editor. For ex. we have more than 80 unit tests for the ENTER button. One of those is hitting the ENTER in a H1 Tag. The current is a release in an early development state and we want to focus on reliability and basic functionality (be able to write without errors) in first step.