The Voog team
Having just spent too much time fighting wysihtml5's overly opinionated rules trying to allow <a> tags to allow any value for href, changes in this area are of great interest to me.
Could you touch on what changed in the parser rules?
They'll see a highlighted word or sentence with a bold font, wider spacing and a blue background. So they set the background blue, the font bold and the spacing wider. But really, the editor should provide an intuitive way to apply the <span class="highlight"> element.
Some editors out there do this, but they generally suck in other areas. Wysihtml seems to apply inline CSS. Can it easily apply a class too?
I can do paragraphs by not manually breaking lines and instead select the second paragraph's content, then apply the "normal text" style, but this isn't exactly intuitive.
Or one could disallow further linebreaks and thus just create paragraphs when you're entering a linebreak.
Like most of WP, the code is ugly, but battle-tested.
We have so many choices when it comes to WYSIWYG. My favorite is https://github.com/daviferreira/medium-editor.
# Clicking the "no-color" option in the text color-picker doesn't do anything.
# Using the "remove" option on a link inserts a space as well as removing the link, which seems incorrect.
# Using the "remove" option on a link doesn't always remove the entire link. Repro on http://wysihtml.com/ by selecting the word "typewriter", adding a link, then clicking on it again and removing the link. Depending on where you clicked either "type" or "writer" will still be linked.
# Repeatedly toggling tags can get weird. e.g. select a word and keep on clicking the bold/italic/underline button, and note how it'll toggle the tag on, toggle it off, and then just start adding spaces in front of it with every subsequent click.
# Possibly related to the spaces issue, after toggling tags for a bit checking the source generated shows a lot of empty-tags, which is kind of messy.
This implies it isn't configurable and unfortunately - in my view this is the incorrect direction to unify in.
Hasn't even MS Word nowadays standardized on Enter=paragraph break, Shift+Enter=line break
https://github.com/narkoz/wysihtml5-rails
Author plans to update it to use wysihtml as a drop-in replacement.
The latest releases of TinyMCE have been easy to work with, and relatively pain free for us.
Try out their beautiful working app: http://voog.com
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…
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.
but why no jquery?
Just asking.
As someone who ported a embedded website away from jquery, it was painful, and I've come to really appreciate it
Assuming you're using contenteditable, a lot of it is about resolving cross-browser differences in the implementation. Probably also reimplementing most of the execCommands since they're wildly inconsistent -- which does involve some DOM manipulation, but is more about using the selection API.
Note: I am using angular for 90% of my stuff.
