The Sorry State of JavaScript XHTML Editors

From reading online reviews, you're likely to think, "wow, standards-compliant WYSIWYG XHTML editing using JavaScript in a web page has finally come of age—there are so many options to choose from!" Well, I've tried them all (all that might even come close to being usable), and they are pitiful, with all sorts of "gotchas" that don't come out in most reviews. The closest to usable is TinyMCE, and that's what I'm using in the latest version of Marmox™ (which is running this site; TinyMCE is the editor I'm using as I write this), but even TinyMCE is incomplete, erroneous, and not quite robust enough.

Here's a list of the JavaScript XHTML editors that are being updated and, from reading the reviews, you would think that have a chance at being usable. I list them in roughly the order of popularity:

TinyMCE

TinyMCE is the best—that is, it's better than the others—but that that doesn't mean it's really "good" in the sense of what I would expect software that's out of beta to be. (It's currently in release 3.x.) It has several features essential for use in Marmox. It allows dynamic inserting and removal of the editing control, and the pre-insertion code is relatively small. (It dynamically loads much of the code and plugins only when needed.)

Also essential is that the XHTML it generates is well-formed and even semantic: italic results in <em>, for instance. Navigation (e.g. Ctrl+Arrow) works like you would expect it to, and it the documentation is almost up to the level of adequate. There are a few shortcomings, such as the editor's only taking up a portion of the screen area (although the auto-resize works reasonably well vertically on Firefox), but that I can forgive for the time being.

Once you use it, however, you find some problems. First Guise™ (the user interface framework Marmox uses) dynamically talks to the server and updates the contents of controls in the Guise data model when the control contents change in the browser. TinyMCE is very nice about this; it has an Editor.onChange() event method that gets called when a new undo level is added. Unfortunately, it doesn't work on IE, so Guise has to use several tricks to make sure that the control sends its contents back to the server before anything important happens (like the user exiting edit mode); otherwise, the last text entered would be lost in Marmox when using IE.

TinyMCE is also incomplete in its XHTML support. By default TinyMCE doesn't let you enter XHTML inline elements like <dfn> or <var>. Surely these can be added through a configuration, though, right? Well, sort of. FCKEditor allows easy configuration of new inline elements, but TinyMCE makes you write an entire plugin just to get a new inline element! You can look at the obtuse code for the supplied XHTMLXtras plugin, but even when you get things working it turns out that TinyMCE will not correctly insert nested inline elements!

The built-in <strong> and <em> functionality supports nesting, because they use special built-in insertion functionality from the browser. So if I make "all these words" <strong> and then add <em> in the middle, I wind up with <strong>all <em>these</em> words</strong>, which is correct. But if I use the code from the XHTMLXtras plugin, insertion collapses the hierarchy to a single level. If I try to do the same thing using <cite> and <del>, for example, I wind up with <cite>all </cite><del>these</del><cite> words</cite>.

FCKEditor

FCKEditor looks spiffy at first—maybe even better than TinyMCE. It even stretches horizontally to fill the entire editing area, and its support for new inline elements is simple. At least, the inline element configuration documentation makes it look that way. I can't say for sure, because I didn't get that far. The editing code is so brittle for producing usable XHTML that, with just a few keystrokes, what should have been simple semantic XHTML becomes:

<h2>this is <code>inter<span style="font-family: Arial,Verdana,sans-serif;">esting</span></code></h2>

Marmox is built on the idea that, whatever editing interface you're using 10 years from now, your data should be in a simple, semantic format that it will still be usable. FCKEditor is so broken that I can't trust it to produce that sort of data.

XStandard

XStandard gets raving reviews for its XHTML compliance. It's supposedly able to give a better user interface because, unlike the editors mentioned so far, XStandard comes, not as JavaScript, but as a native control that you embed using the <object> tag. I'd have liked a JavaScript-only solution, but at this point I'll take anything that works—and XStandard supposedly supports the major browsers.

Also unlike the other editors mentioned here, XStandard is not open source, and its "pro" version requires a licensing fee. One would think that with such emphasis on XHTML standards support, along with a commercial business model and a native control, that the user interface would be superb. But the XStandard user interface sucks. If I want to create a definition list, it pops up a dialog to define the number of items (imagine a clumsy table creator), and then places in essence separate controls for each <dt> and <dd> part of the definition list. Even TinyMCE is better than this for definition lists. And if XStandard allows nested lists, I couldn't figure out how.

XStandard has some nice features, such as custom elements and change notification, but these require that the "pro" license be purchased. The entire XStandard interface is clumsy, and not worth the effort of going for a native control—and a non-open-source one at that.

WYMEditor

This one has been getting kudos everywhere, and it's a great concept: instead of concentrating on what the content looks like, the editor concentrates on the structure and meaning of the data. I say it's been getting kudos for a long time, because it's been in its current state for a long time: unusable. It has stagnated in an alpha state that cannot be used for real-life data, and there are no signs that anything is moving forward any time soon. The documentation is virtually non-existent, and the editor is sporadic. There seems to be no way to add a new paragraph between an <h1> and an <ol>, for example, not to mention the apparent inability to create nested lists. WYMEditor was and is a great idea, but it's nowhere near a level I can trust, and I'm not placing bets on it advancing any time soon.

YUI Editor

The Yahoo! UI Rich Text Editor is part of Yahoo!'s extensive, flashy, well-documented user interface library. There are even complete videos explaining how the components are used. Pressing Ctrl+I doesn't give me <em>, and I see no way to add other XHTML inline elements such as <dfn>. Furthermore, "paragraphs" are separated by <br>. If you want to make a block-level element such as <h1> or (gasp!) <p>, you're required to discover the trick of selecting more than one line (i.e. enough characters to include a preceding line break) before the block elements drop-down list even becomes enabled. The YUI editor has lots of fluff around it, but it doesn't do the job of a real, usable XHTML editor.

Kupu

This editor hasn't been updated since 2006-02-03. There are no online demos at the site, and half the links to supposed demos at other sites point to pages that no longer exist. I'm not going to waste my time trying something that isn't actively being maintained and that I can't even test without significant work.

NicEdit

This is an editor no one seems to be talking about, written by an apparently bright young man based upon the best code of other projects. This is the project I have the highest hopes for if the author keeps up the level of activity to bring it to usable quality. It's still relatively new, but it has some very promising aspects such as the ability to turn any <div> into an editable area! (I assume this would obviate the need for kludgy iframe auto-expansion.)

Unfortunately it's still not well cooked. There are a couple of usability show-stoppers: I can't use Ctrl+Arrow to navigate among words, and I can't hit Ctrl+I to turn on <em>. But the worst part is that it doesn't put out semantically clean XHTML at all. Just adding a single line to the demo generates this monstrosity:


<br><br>This is <span style="font-weight: bold;">strong text with <span style="font-style: italic;">emphasized</span> in the middle</span> of it.

This is absolutely unacceptable XHTML output. But everything looks very slick, and if the author has the motivitation, there's a good chance that NicEdit could turn into something very nice.