Mark D. Anderson (mda@discerning.com)
Created 2004 Nov 15
Rewritten 2007 May 19
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 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 xstandard.com
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 .
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.
Instead of WYSIWYG, there are some javascript editors for wiki or other markup. See for example Control.TextArea.
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.
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.
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 lussomo.com, with credits to Sean Christman. It is also possible to get Flash to exchange clipboard data with JavaScript.
There are a few good link farms and reviews of ttw editors, including:
I examine only open source solutions, excluding the many commercial ones, which are generally superior.
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:
| Editor | Pros | Cons |
|---|---|---|
| Dojo | none? | documentation is practically non-existent; no image chooser |
| Ext | nice tooltips, works in Safari | no image picker |
| FCKeditor | nice language-independent protocol for file browsing | architecture seems not to distinguish between block and span formatting. |
| FreeRichTextEditor | sort-of supports Safari 2.x | not really open source. |
| TinyMCE | does toolbar state on links well | The “Styles” menu requires hacking to be usable |
| Whizzywig | small and fast | too much hard-coded behavior. It has some usability problems, for example not showing current formatting state in the toolbar. No style support. |
| WYMeditor | strong dedication to clean semantic XHTML | not any more usable than others, and is worse in some respects. Still beta. |
| YUI | Safari support | beta quality; no class/style support |
| Xinha | multiple 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.
AFL.
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.
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:
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 http://freerichtexteditor.com/page/2.htm says distributions must be unmodified – which means it is not open source.
Good cross-platform support.
LGPL
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 http://www.phpletter.com/.
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 http://ajaxian.com/archives/yui-23-released-rich-text-editor-components-and-themes ).
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:
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 http://wakka.xiffy.nl/WYSIWYGrte
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.
GPL. no demo. no public docs.
GPL.
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.
LGPL.
only a basic insert image popup. no Safari support. easy to integrate. does not produce clean xhtml.
still Gecko only
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: http://www.onlamp.com/pub/a/onlamp/2005/04/28/kupu.html with associated scripts at http://www.craic.com/oreilly/kupu/
[This section not updated since 2005]
Typepad has announced “rich text editing”: http://typepad.com/resources/2004/11/richtextediti.html They are using a hacked htmlarea v3: https://www.typepad.com/app-static/js/htmlarea.js
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.