Through-The-Web (TTW) Editors

Mark D. Anderson (
Created 2004 Nov 15
Rewritten 2007 May 19

Editing Technologies


Most javascript-based ttw editors use contentEditable on IE and designMode in Gecko.

Internet Explorer was the first to come out with designMode. The Mozilla project then followed with its incompatible version of designMode, called Midas (see also Midas). It is like IE’s designmode, except different of course.

The “designMode” support works at the whole document level, and so basically requires the edited content to be put in an iframe.

Internet Explorer then introduced contentEditable which unlike designmode allows any element to be editable (not just the whole document). See also How to Create An HTML Editor Application. Mozilla followed with yet another incompatible editing API called Mozile. It uses CSS -moz-user-modify; it is kind of like contentEditable, except different of course. Mozile is not used by most ttw editors.

Microsoft also introduced execCommand which acts on TextRange objects. The API takes explicit commands such as “Bold”, “Indent”, “InsertImage”, “InsertParagraph”. Mozilla and most other browsers followed up with implementations of the execCommand API.

The ugly part of this technology foundation is that they require dealing with the browser’s internal HTML DOM model of the document – basically what you get if you ask for an element’s innerHTML. The discrepency from the original source is further with IE, but Gecko has issues too; it may stick in implicit p and tbody tags, for example.

In addition to variations in innerHTML, browsers are also inconsistent in their execCommand implementations. For example, Opera and IE implement the “Bold” command by making the selection <strong> while FireFox does it using <b>. Safari does it using a ’<span style=”font-weight: bold”>…’. The execCommand implementations also liberally insert &nbsp; in empty elements. For more discussion see execCommand compatibility .

The execCommand API is rather ugly. For example, the “FormatBlock” command will set the current containing block’s element type (h1, p, etc.). It does not support setting the classname at the same time; you have to do something like this:

range.execcommand("formatblock",false, "<p>") 
var el = range.parentElement(); 
el.className = "someclass"; 

Furthermore, at least in IE, FormatBlock only accepts certain elements (P, H1 - H6, ADDRESS, and PRE), excluding for example <blockquote>. See also some criticisms by a representative of

Some ttw editors use a server-side tidy process to clean up the mess made by the browser.

Opera 9 has support for contentEditable. Safari added half-assed support for it in 1.3.9 in late 2004. Safari 3.0 to be released with OSX 10.5 is supposed to have real support.

There is a draft specification by whatwg .

XML Editing

Both IE and Gecko-based browser have builtin support for XML editing.

Some Gecko-specific ttw editors that use Mozile and therefore are capable of editing XML, XHTML, and the radical concept of preserving the original source – WYTIWYG (what you type is what you get). Editors using Mozile include bitflux and xul editor. In addition to being browser-specific, these are currently ugly, hard to use, and lack features. Except for the browser-specific part, this is not necessary, as the commercial ajaxWrite demonstrates.

Another approach to supporting arbitrary XML is to use client-side XSLT or other client-side XML apis, to transform the original into some editable XHTML fragments. These still rely on the browser’s native contentEditable equivalent, but because they transform too and from XML in small chunks, the messes of innerHTML are less of a problem. Some that do this are Xopus and Microsoft’s demo application Xopus worked on Gecko before Q42 took it closed source; now it is IE-only.

The importance of XML-based editing is that it can be schema driven, and that is useful even for just XHTML, where you may want to control what elements and attributes are used. You may want to have a menu of elements, etc.

Markup Editors

Instead of WYSIWYG, there are some javascript editors for wiki or other markup. See for example Control.TextArea.

Non-Web Technologies

There are a variety of other client-side editors that rely on Java (e.g. ActivEdit, edit-on Pro), ActiveX (e.g. XStandard), or Flash (e.g. eWebWP). They avoid the reliance on the builtin browser editing facility, exchanging that for the consequences of their own technology base: Java takes out the browser; ActiveX is Windows-specific; and Flash has limitations in its builtin HTML support (so I’ve heard, anyway it is otherwise hard to understand why eWebWP would be Ektron’s entry-level product as compared to the eWebEditPro).

Of course, if your content is directly available via webdav/ftp, then at least some users can perform updates via a “native” html editor. You’d still have to deal with the fragment vs. document problem.

Microsoft offered an ActiveX editing control in IE5 and IE6, but not in IE7. post by microsoft manager.

Copy and Paste

Internet Explorer and Safari allow cut, copy, and paste with the user’s desktop clipboard to be scripted. All browsers allow users to explicitly interact with the desktop clipboard by typing Control-X, Control-C, and Control-V (Command-X, Command-C, and Command-V on a Mac) – or by selecting the same operations from the browser Edit menu.

Normally when a user pastes into a textarea, the clipboard contents is pasted as plain text (even if it came from some rich text source like Word). But a paste into a contentEditable/designMode area enters as whatever kind of mangled HTML that the originating application and receiving browser conspire to generate.

This is not particular to Word and IE. The same html pasting issue is also true, for example, when pasting from OpenOffice Writer into FireFox on Linux, or from TextEdit into Safari on OSX. The combinations do vary in how awful the pasted HTML is, but the problem of cleanup remains. (Note that not all combinations are possible; FireFox and Opera on OSX seems not to take rich text paste; always taking plain contents instead, but Safari supports it. The situation is actually more complicated as the clipboard might contain text, RTF, and/or HTML, and the receiving side would ideally know to convert RTF to HTML if only RTF is available. See also this in depth discussion of OSX browsers and the clipboard )

It is possible to intercept the Control-V (Command-V) keystroke and do your own processing (or ignore it). This is as with any keyboard event processing, the solution is browser-specific (for example, Gecko does not generate keypress events for modifier keys but keypress must be intercepted to prevent default handling – but for example, check for event.keyCode = 86 && event.ctrlKey for ctrl-v). It is not possible to intercept the browser “Paste” menu item. There is also the default context menu (which might be overridden), which also has a paste command in some browsers. And on some systems, clicking both bottons of a two-button mouse also does a paste, so does typing SHIFT-INSERT.

In IE, the browser can choose to paste plain text using the clipboardData.getData method, instead of execCommand(‘Paste’).

Note that most editors also allow raw HTML editing, so some level of protection against bad html is necessary regardless.

Making Copy and Paste Scriptable

Since users can copy and paste with keyboard or browser menu, it isn’t a usability disaster that some browsers prevent scripting of clipboard copy and paste (so there can’t be a toolbar button for it).

FireFox users can configure their browsers to allow scripting of clipboard access (yeah, like that will happen).

Note that starting with version 7, Flash has a System.setClipboard function but not a corresponding System.getClipboard. A _clipboard.swf without source is used in, with credits to Sean Christman. It is also possible to get Flash to exchange clipboard data with JavaScript.

Other Comparisons

There are a few good link farms and reviews of ttw editors, including:

This comparison

I examine only open source solutions, excluding the many commercial ones, which are generally superior.

Features/Issues to Consider

Safari and Opera support
Opera 9 and the latest Webkit should work. Safari 2.x should work up to the limits of its execCommand implementation.
Separate block and span formatting
Users expect “paragraph styles” and “character styles”. They don’t expect one menu for html element types and another menu for CSS classes. This requires internal support for distinguishing span and block styling.
Blockquote support
Many purists would decry “indent” being available or being implemented as blockquote. Whether that is the case, it should be possible to have a container such as blockquote around multiple paragraphs. There should be an apparent visible difference between a single blockquote and two adjacent ones.
Return key handling
Regardless of what the browser does when left to itself, there needs to be a configuration option to force all returns to be treated as new paragraphs.
Bold and Italic
Regardless of what the execCommand implementation does, there should be a configuration option to force the saved html to have either b/i or strong/em.
XHTML support
It should be possible to ensure that the saved output is well-formed xml, at least if wrapped with a surrounding <div>. It should also be possible to ensure that no <font> or other deprecated tags are used. This means it has to manage such eventualities as a user trying to bold a selection across multiple partial paragraphs, or have overlapping bold and italic regions.
Image support
Ideally there should be a basic image popup that just specifies url, alt, title, and CSS class, as well as a more complex alternative that allows thumbnail browsing of a configured path and optional upload.
Undo/Redo should work for all operations, at least to a stack of depth 20 or so.
It should be easy to remove or reorder the toolbar.
It should be easy to add a new custom button or select menu in the toolbar.
It should load quickly and have good responsiveness thereafter.
It should be possible to easily toggle a “maximized” (full window) and minimized (original) editing view.
HTML Paste
Regardless of whether it is done via Control-V or a toolbar button (in IE and Safari), pasted HTML should be cleaned up, ideally as soon as it is inserted, but certainly at save time.
Toolbar State
As a user moves around in the editable region, the Bold/Italic buttons should change state, as should any paragraph or character style menus. When a user moves to or selects an image, any image button should allow for editing that image, not creating a new one. When a user moves to or selects a link, the link should not be followed and the link editing buttons should reflect the state.
Customizable CSS
It should be possible to provide the CSS file that controls the display of the edited html.
URL preservation
By and large, it should not mess with URLs in img, script, and other elements. This is difficult because the browser DOM in some browsers does this anyway.
Document or Fragment editing
It should be capable of editing an entire html document (including doctype) or just a fragment (with no root element).

Image Managers

What with all the AJAX hype, there are now several standalone popup image browsers/pickers/choosers/managers which can be used in place of the bundled ones that come with some ttw editors:

Summary Conclusions

Dojonone?documentation is practically non-existent; no image chooser
Extnice tooltips, works in Safarino image picker
FCKeditornice language-independent protocol for file browsingarchitecture seems not to distinguish between block and span formatting.
FreeRichTextEditorsort-of supports Safari 2.xnot really open source.
TinyMCEdoes toolbar state on links wellThe “Styles” menu requires hacking to be usable
Whizzywigsmall and fasttoo much hard-coded behavior. It has some usability problems, for example not showing current formatting state in the toolbar. No style support.
WYMeditorstrong dedication to clean semantic XHTMLnot any more usable than others, and is worse in some respects. Still beta.
YUISafari supportbeta quality; no class/style support
Xinhamultiple community developers“Stylist” plugin requires hacking to be usable. bundled imagemanager is a bit of a mess internally. The toolbar is pigheadedly disabled by default.

In summary, none of them is great. Forced to choose, I’d take TinyMCE. Dojo will be worth another look if/when they produce real documentation. WYMeditor will be worth another look after it stabilizes a bit, 0.3 is released, and they fix some of the usability issues.

Reviewed Editors

Dojo RichEdit


There is an almost complete lack of documentation, and what exists is sometimes woefully out of date. (The original “Editor” was a wrapper around RichText; it was replaced by “Editor2” which is now called “Editor”.) Some information can be gleaned from the blog of the primary Editor2 developer. There is an ajaxian discussion on Editor1 from 2005.

Ext HTMLEditor

LGPL license.

No image picker, no class support, no XHTML.


GPL/LGPL/MPL triple license. Primarily by Frederico Caldeira Knabben.

Has been a one-person show, but recently started opening up, and is now acting like a well-managed project.

Has a good list of outstanding issues on compatibility:

It has a multiplicity of solutions for image insertion. They have a clean XML-based protocol for re-implementing the backend in different programming languages. The builtin one has small tabbed image popup with another big “browse server” popup from there. Has the improved MCPUK ImageManager

There are plugins for several CMS/blogging tools:

Some comments on FCKEditor

FCKeditor seems not to distinguish span vs. block styles at all in any of its styling alternatives:

Review items:


It states that it is under the CC Attribution 2.5 license. Note that this implies derivative works are allowed; creative commons has a different license to limit derivative works. However, the says distributions must be unmodified – which means it is not open source.

Good cross-platform support.



Moxie wants to sell MCImageManager and MCFileManager. TinyMCPUK seems not maintained. There are quite a few alternatives for image management though, such as Gallery2 and IMCE and

Formatting choices:

Review items:


MIT license (whizzypic.php and whizzylink.php are GPL).

The author wrote a nice rant (note this says it is GPL’d, but it isn’t).

ofbiz adopted it over tinymce.


MIT/GPL dual license. Primarily by Jean-Francois Hovinne.

Good philosophical bent, though behind other editors even in its limited features right now. Uses contentEditable just like everyone else, but works hard at cleanup.

The image inserter has no server-side browse, with no plugin available for anything better.

There are substantial limitations in v0.2:

In the current version (v0.3):


bsd-style license.

In beta as of Aug 2007. Some issues (see comments at ).

At the moment, still slow (double-clicking a word takes 5 seconds to select!).

Basic issues:


bsd-style license. Originally based on htmlarea. AreaEdit is a fork of Xinha .

Xinha has a fair number of plugins. Some of them in particular are helpful in producing more “semantic” html:

There are multiple image popups:

Review items:

Other Editors


GPL. Simple. Fails in Safari.


originally public domain, now CC, with uncompressed source available only for purchase for $49.95. simple. works in safari.

has a demo


See also

bsd license. originally a fork of RTE, now mostly new code. does not work in Safari; just a plugin.

uses a fork of the Zhuo image manager.


Unrelated to the other TinyRTE; seems to really be TinyMCE


Another spinoff from Kevin Roth’s RTE. Doesn’t seem to add much.

Helmi RIA Client

GPL. no demo. no public docs.



has nice image popup and table support. no Safari support.

requires a fair amount of js to setup (in Loki 2 beta). Seems to be frozen. Seems somewhat based on TinyMCE.



only a basic insert image popup. no Safari support. easy to integrate. does not produce clean xhtml.

BitFlux (BXE)

still Gecko only

had a 2.0 rewrite in 2005


Kupu appears to have a nice image picker, but, like, they have no demo, and no easy way of installing. After 3 years. Sigh.

Extreme googling turns up a demo

Kupu is too much of a bear to install and integrate with. (I could be nice and say “oh, it must be for the ‘enterprise’“, but i won’t.)

A good article on Kupu that actually makes it possible to install: with associated scripts at

Who is Using What

[This section not updated since 2005]

Typepad has announced “rich text editing”: They are using a hacked htmlarea v3:

Yahoo Mail has a “rich text editor” available for composing messages. It is Window/IE-only. It appears to be homegrown. It does not use contentEditable, but just TextRange objects.

Hotmail has a browser-based html editor that runs only on Windows. It relies on an iframe. Like Yahoo, it is limited in features; toggling into plain text loses all formatting, and there is no support for images.