Content Editable Text Editors

Question

I have tried out several HTML editors including TinyMCE, CKEditor and now NicEdit. NicEdit is good in one respect - it is very easy to customize. However, I have found that they all have a tendency to produce very poor HTML. Not necessarily so but because they don't do much to correctly interpret invalid user actions such as attempting to style something without first having made a selection.

It is far too easy to end up with HTML that contains something like

<span style='color:#ff0000'><span style='color:#ff0000'><span style='color:#ff0000'>Red</span></span></span>

Am I right in thinking that this is pretty much a limitation of the content editable concept? The poor HTML does not matter much if the purpose is email or posts on forums such as this but gets rather uncomfortable to live with if the generated HTML has to be used in the context of a web page. If all of this is right what are the alternatives? Perhaps a Flash based plugin editor that produces better HTML and works harder at interpreting what the user wants to do?

I suppose it would in principle be possible to study the generated output and clean out everything between concertina'd spans if required but that is liable to be quite an undertaking.

Answer 1

At the beginning I should mention that I'm a CKEditor core developer, thus my opinion may not be fully objective :).

The state of HTML editing AFAIK hasn't changed for the last few years. Browsers vendors have spent little time fixing bugs - so little that most of the oldest bugs on CKEditor trac that were caused by browser issues are still valid and most of hacks we've ever created are still required. And I don't only mean IE 7 or 8 which we still support, because in fact IEs may not be the worst. I haven't checked that precisely, but I think that thanks to general improvements for DOM APIs in recent IEs versions they may require less hacks than other browsers, because its editing support seems to be the most stable and complete. E.g. the ugliest hack ever is needed for Webkit browsers (see: Webkit bug and closed CKEditor ticket) and this bug is 5 year old. What's more - this isn't an edge case or unlikely scenario - this issue makes it impossible to create whole range of selections - e.g. inside an empty inline element IIRC.

So, unlike the web technologies in general, HTML editing stands where it was left 10 years ago. The same bugs, the same missing features, the same... markup. Guess what is created by the fontName command? <font face=""> - yep, not joking. At least browsers are very consistent here... But the consistency very quickly disappears.

What about the spec? There's a draft, but it does not help at all - it just standardizes the current state, which as we know does not look very well. And AFAICS, the draft is dead.

And there's one more thing that worries me - direction in which editing goes. Google uses contenteditable in Gmail (no, Google Docs is not built on contenteditable), so it does not care about HTML output. Apple reuses HTML editing component in their email app for iOS and perhaps in Mail for MacOS (because I see the same specific behaviours). Mozilla reuses Gecko in Thunderbird and I it wouldn't surprised if Microsoft does the same in Outlook. All of them do not care about HTML output. These engines are made to understand every crap rather than fix it and the HTML Editing draft is all about it.

Thanks to all of that, we can see new issues like this one. In the Blink/Webkit bug report I summarized whole range of incorrect (from our POV - devs who care about HTML) results when pressing backspace. It is designed to look nice (although it does not), but the HTML and editing APIs are not important.

I don't care about this. I need an editor!

The solution to all of that is fixing everything after browsers and/or replace their native implementations by our own. For the last 1.5 years I've been working nearly exclusively on filtering and normalizing input and output. In CKEditor 4.0 we rewrote entire pasting and HTML insertion processes and in recently released CKEditor 4.1 we introduced the Advanced Content Filter which adapts input data to the editor configuration. So the less features are enabled, the less will be allowed in HTML. Check this sample - try to paste/write/create crappy HTML.

Of course, there's still a room for improvements. E.g. we are not able to filter data immediately during editing. If browser (like Webkit) creates a mess we can fix that on output, but in fact we haven't decided to do that because filtering is really complex process and could spoil the performance. We limit input and user actions so one day we will implement our own backspace/delete handlers to prevent browsers from messing our HTML. That's the only solution and this is why there are just 2 or 3 good WYSIWYG editors.

Anyway, nearly nothing has changed in browsers' HTML editing implementations, but a lot has changed in WYSIWYG editors world. I advice you to check them again if you base on your experience from few years back.

Answer 2

Having spent a great deal of time trying to find ways of ensuring that I get production grade HTML out of a WYSIWYG editor I thought I should share my results here for the benefit of anyone running into this thread.

Very brief recommendation - stop wasting your time. Content editable editors are never going to deliver anything even remotely close to production grade HTML. People like Reinmar have done a great deal of work to minimize this but it is all too easy for the user to throw the underlying browser code that handles content editable into a tizzy.

You are better off using BBCode markup. The 100% bullet proof option is to make the user edit the BBCode and keep a tight reign on what he/she is allowed to do at any point. I have done this in my own project but the issue with making non-techie users play with markup of any description is a tricky one. Putting your own WYSIWYG interface for BBCode editing is a job not to be undertaken lightly. Luckily, help is at hand in the form of SCEditor. Sam has done an outstanding job here. Be aware - what comes out can still contain a few "soupy" bits since the WYSIWYG bit still relies on content editable. However, it is relatively easy to clean up.