Why fork something that is incomplete, unstable, has very limited test coverage, and doesn't tightly control the generated markup?
CKEditor has had the ACF (Advanced Content Filter) for >1.5 years now. It allows you to very tightly control which tags and attributes are allowed.
This feature, and the rest of CKEditor has much, much more test coverage to account for the many browser quirks (notably in contentEditable) that they have had to work around, to prevent regressions.
It's a waste of time for everybody to solve the same problems and work around the same browser quirks over and over again.
The "Ability to add uneditable area inside editor text flow (useful when building modules like video tools, advanced image editor etc)." feature is probably the only interesting feature. But it's nothing compared to CKEditor Widgets, which does exactly this, and much more (think storing structured content but transforming it to the specific markup that a frontend developer wants).
Just compare Wysihtml's "advanced" demo to the CKEditor Widgets demo: http://docs.ckeditor.com/#!/guide/dev_widgets
I took part in a hackathon a few weeks ago and we needed a text editor that we could easily implement and customize. In particular, we wanted more control over the appearance of the toolbar -- we wanted to use our own buttons and move them vertically to the left of the text area -- and needed to capture events related to entering text.
We started with CKEditor, found it far too complicated and with a ton of old and unclear documentation floating around, and had to work against its default features to get it scaled back to the minimal editor we wanted. We weren't able to move the buttons to the left-hand side and couldn't style them as easily as we wanted to. Maybe it's buried deep in the docs somewhere but I couldn't tell you, there's a lot there and it's overwhelming for someone who's just getting started and on a time constraint.
Frustrated, we switched to WYSIHTML5 and were able to get exactly what we were looking for very quickly.
I've come to see CKEditor as the WordPress of WYSIWYG text editors: it aims to do ABSOLUTELY EVERYTHING for everyone, but that's not what everyone is looking for. Maybe things would have gone differently if we weren't under the gun but when we were in a pinch, we found WYSIHTML5 to be a much better option.
CKEditor has had the ACF (Advanced Content Filter) for >1.5 years now. It allows you to very tightly control which tags and attributes are allowed.
This feature, and the rest of CKEditor has much, much more test coverage to account for the many browser quirks (notably in contentEditable) that they have had to work around, to prevent regressions. It's a waste of time for everybody to solve the same problems and work around the same browser quirks over and over again.
The "Ability to add uneditable area inside editor text flow (useful when building modules like video tools, advanced image editor etc)." feature is probably the only interesting feature. But it's nothing compared to CKEditor Widgets, which does exactly this, and much more (think storing structured content but transforming it to the specific markup that a frontend developer wants). Just compare Wysihtml's "advanced" demo to the CKEditor Widgets demo: http://docs.ckeditor.com/#!/guide/dev_widgets
See http://docs.ckeditor.com/#!/guide/dev_advanced_content_filte... for more about ACF and http://docs.ckeditor.com/#!/guide/dev_widgets for more about Widgets.
And yes, it's open source: GPL/LGPL/MPL/commercial: http://ckeditor.com/about/license
If we'd collaborate more rather than reinventing the wheel, we'd get so much further. One does not just write a WYSIWYG editor…