Through-The-Web (TTW) Editors

Mark D. Anderson (mda@discerning.com)
Created 2004 Nov 15
Rewritten 2007 May 19
* Table of Contents {:toc} # Editing Technologies ## contentEditable/designMode Most javascript-based ttw editors use contentEditable on IE and designMode in Gecko. Internet Explorer was the first to come out with [designMode](http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/designmode.asp). The Mozilla project then followed with its incompatible version of designMode, called [Midas](http://www.mozilla.org/editor/midas-spec.html) (see also [Midas](http://developer.mozilla.org/en/docs/Midas)). It is like IE's designmode, except [different](http://www.mozilla.org/editor/ie2midas.html) 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](http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/contenteditable.asp) which unlike designmode allows any element to be editable (not just the whole document). See also [How to Create An HTML Editor Application](http://msdn2.microsoft.com/en-us/library/ms537834.aspx). Mozilla followed with yet another incompatible editing API called [Mozile](http://mozile.mozdev.org/). 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](http://msdn2.microsoft.com/en-us/library/ms536419.aspx) 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](http://www.quirksmode.org/dom/execCommand.html) . 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, "

") var el = range.parentElement(); el.className = "someclass"; Furthermore, at least in IE, [FormatBlock](http://msdn2.microsoft.com/en-us/library/ms536993.aspx) only accepts certain elements (P, H1 - H6, ADDRESS, and PRE), excluding for example <blockquote>. See also some [criticisms by a representative of xstandard.com](http://www.accessifyforum.com/viewtopic.php?p=50928#50928) 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](http://www.whatwg.org/specs/web-apps/current-work/multipage/section-contenteditable.html) . ## 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](http://us.ajax13.com/en/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](http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxmlweb/html/xmldocedit.asp) 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](http://livepipe.net/projects/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](http://blogs.msdn.com/ie/archive/2006/06/27/648850.aspx). # 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](http://hsivonen.iki.fi/kesakoodi/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](http://msdn2.microsoft.com/en-us/library/ms536436.aspx) 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](http://www.mozilla.org/editor/midasdemo/securityprefs.html) (yeah, like that will happen). Note that starting with version 7, Flash has a [System.setClipboard](http://livedocs.adobe.com/flex/2/langref/flash/system/System.html) function but not a corresponding System.getClipboard. A \_clipboard.swf without source is used in [lussomo.com](http://webchicanery.com/2006/11/14/clipboard-copy-javascript), with [credits to Sean Christman](http://lussumo.com/docs/doku.php?id=filebrowser:docs). It is also possible to get [Flash to exchange clipboard data with JavaScript](http://www.actionscript.org/actionscripts_library/External_Communication/more2.shtml). # Other Comparisons # There are a few good link farms and reviews of ttw editors, including: - [http://www.geniisoft.com/showcase.nsf/WebEditors](http://www.geniisoft.com/showcase.nsf/WebEditors) - [http://meta.wikimedia.org/wiki/WYSIWYG](http://meta.wikimedia.org/wiki/WYSIWYG) A comparison of TinyMCE, FCKEditor, Mozile, and others. - [http://blog.ianbicking.org/evaluating-wysiwyg-editors.html](http://blog.ianbicking.org/evaluating-wysiwyg-editors.html) lots of hearsay. - [http://www.standards-schmandards.com/2007/wysiwyg-editor-test-2/](http://www.standards-schmandards.com/2007/wysiwyg-editor-test-2/) [http://www.standards-schmandards.com/2006/wysiwyg-editor-test](http://www.standards-schmandards.com/2006/wysiwyg-editor-test) [http://www.standards-schmandards.com/exhibits/wysiwyg/result.html](http://www.standards-schmandards.com/exhibits/wysiwyg/result.html) The basic result seems to be that the open source ones suck, but the top ones (XStandard and EditOnPro) aren't pure javascript solutions. # 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 : Undo/Redo should work for all operations, at least to a stack of depth 20 or so. Customizability : It should be easy to remove or reorder the toolbar. Extensibility : It should be easy to add a new custom button or select menu in the toolbar. Performance : It should load quickly and have good responsiveness thereafter. Maximize/Minimize : 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: - [Kae's File Manager](http://kfm.verens.com/) MIT license. php. can be used with FCKeditor. Seems not to work with Safari. Has a table of [comparisons with other file managers](http://kfm.verens.com/Comparisons&search=comparison) - [Relay](http://ecosmear.com/relay/download.php) MIT license. php, with perl for download progress. Seems a little buggy as of this writing. - [ImageManager](http://sourceforge.net/projects/imgmngedt/) by Xiang Wei Zhuo. MIT license. Originally for htmlarea, now forks are available for Xinha and TinyMCE. Not modified since 2004. Has been used to make a [WordPress plugin](http://www.soderlind.no/archives/2006/01/03/imagemanager-20/) - [ImageEditor](http://www.ajaxprogrammer.com/?p=9) LGPL license. in php. Image editor, not specifically an image chooser. - [http://codex.wordpress.org/Plugins/Images](http://codex.wordpress.org/Plugins/Images) list of many for WP, including: -- [http://www.bistr-o-mathik.org/code/wordpress-plugins/](http://www.bistr-o-mathik.org/code/wordpress-plugins/) -- [http://fredfred.net/skriker/index.php/iimage-browser](http://fredfred.net/skriker/index.php/iimage-browser) - [http://dmoz.org/Computers/Programming/Languages/PHP/Scripts/Image\_Galleries/](http://dmoz.org/Computers/Programming/Languages/PHP/Scripts/Image\_Galleries/) Mostly designed for full page, but could probably be adopted for a popup. for example GPL PHP [Wabbit](http://wabbit.arnoldcistai.net/index.php) - [jMaki](http://www.javaserver.org/jmaki/) has its own implementation of an Image Browser. BSD license. - [YUI-Ext demo](http://www.jackslocum.com/blog/2006/12/17/how-to-create-a-reusable-ajax-driven-web-dialog-a-working-example/) bsd license. See also [chooser](http://www.yui-ext.com/deploy/yui-ext/docs/#../examples/view/chooser.html) and [YUI carousel](http://billwscott.com/carousel/) - [Adobe Spry](http://labs.adobe.com/technologies/spry/demos/gallery/#) bsd license. Flash-based gallery. See [article](http://labs.adobe.com/technologies/spry/articles/photo_album/) - [Gallery2 Image Chooser](http://g2image.steffensenfamily.com/index.php?title=Main_Page) for TinyMCE, WordPress, or standalone (allegedly FCKeditor soon). GPL. - [IMCE](http://drupal.org/project/imce) for TinyMCE or PCKEditor. See [demo](http://ufku.com/drupal/imce/demo) - [dynamicdrive thumbnail](http://www.dynamicdrive.com/dynamicindex4/thumbnail.htm) [dynamicdrive popup image viewer](http://www.dynamicdrive.com/style/csslibrary/item/css-popup-image-viewer/P20/) - [iManager and iBrowser](http://j-cons.com/main.php?pbcat=about&pbid=intro&title=intro) iManager is LGPL; iBrowser is GPL. in PHP. iManager does manipulation. works with several different ttw editors, including Xinha. except now they seems dead. # Summary Conclusions 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](http://xinha.python-hosting.com/ticket/593).| 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](http://dojotoolkit.org/) ## 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](http://www.liucougar.net/blog/archives/category/project/dojo/). There is an [ajaxian discussion](http://ajaxian.com/archives/dojo-rich-wysiwyg-editor) on Editor1 from 2005. - Demo: [demo 0.2.2 of Editor1](http://download.dojotoolkit.org/release-0.2.2/dojo-0.2.2-widget/demos/widget/Editor.html) [demo 0.4.3 of Editor1](http://download.dojotoolkit.org/release-0.4.3/dojo-0.4.3-widget/demos/widget/Editor.html) [demo 0.4.3 of Editor2](http://download.dojotoolkit.org/release-0.4.3/dojo-0.4.3-widget/tests/widget/Editor/test_Editor2.html) [demo hosted by Liucougar, a dojo developer](http://dojotoolkit.org/~liucougar/dojo/src/widget/templates/Editor2/test_EditorToolbarFullFeature.html) Most of these demos fail and/or generate debugging error messages. - Images: no image picker - Documentation: Has some of Editor2 at [documentation](http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book78) and [documentation2](http://dojotoolkit.org/node/64) which lists the few plugins available. - At least the older Editor works in Safari?: http://dojotoolkit.org/node/204 ## [Ext HTMLEditor](http://extjs.com/deploy/ext/examples/form/dynamic.html) LGPL license. No image picker, no class support, no XHTML. ## [FCKeditor](http://www.fckeditor.net) 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: - [Opera Compatibility](http://dev.fckeditor.net/milestone/Opera%20Compatibility) - [Safari Compatibility](http://dev.fckeditor.net/milestone/Safari%20Compatibility) 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](http://fckeditor.prosjektweb.net/) There are plugins for several CMS/blogging tools: - WordPress has [ChenPress](http://www.pixelficker.com/chenpress-wysiwyg-for-wordpress/) [Some comments on FCKEditor](http://www.phpsolvent.com/wordpress/?page_id=330) FCKeditor seems not to distinguish span vs. block styles at all in any of its styling alternatives: - The ["Style"](http://wiki.fckeditor.net/Developer's_Guide/Configuration/Styles) menu is defined in fckstyles.xml and is quite flexible; it can specify both element and attribute. It does not distinguish span vs. block styling. If nothing is selected, it simply inserts an empty element. It also [nests styles](http://dev.fckeditor.net/ticket/265) which users may find counterintuitive. - The "FontFormat" menu is not easily configurable and is just element types. - The [dynamic CCS plugin](http://sourceforge.net/tracker/index.php?func=detail&aid=1448301&group_id=75348&atid=737639) scans a stylesheet and puts it into a combobox; still no distinction between block and span. There is a new improved [Style System](http://dev.fckeditor.net/wiki/Components/Styles) feature in Sept 2007; see [changeset](http://dev.fckeditor.net/changeset/774) Review items: - Demo: [demo](http://www.fckeditor.net/demo) - Extensibility: any new toolbar buttons requires a whole plugin to be made. Has ["template"](http://wiki.fckeditor.net/Developer%27s_Guide/Configuration/Templates) support, but they must be buried in the templates menu. There is no way to easily configure it with buttons to insert templates (vs. popup dialog). - Shows path: no (though there is the [extended nodepath plugin](http://sourceforge.net/tracker/index.php?func=detail&aid=1455334&group_id=75348&atid=737639) - separates block and span formatting: not really, see above. - Safari: no - Plugins: [many](http://sourceforge.net/tracker/?group_id=75348&atid=737639) - [Configuration] (http://wiki.fckeditor.net/Developer%27s_Guide/Configuration/Configurations_Settings) ## [FreeRichTextEditor](http://www.freerichtexteditor.com) It states that it is under the [CC Attribution 2.5](http://creativecommons.org/licenses/by/2.5/) license. Note that this implies derivative works are allowed; creative commons has a [different license](http://creativecommons.org/licenses/by-nd/2.5/) to limit derivative works. However, the [http://freerichtexteditor.com/page/2.htm](http://freerichtexteditor.com/page/2.htm) says distributions must be unmodified -- which means it is not open source. Good cross-platform support. - Demo: [demo](http://freerichtexteditor.com/page/3.htm) - Safari: works, mostly. - Image Insertion: simple dialog; no graphic image picker. - block formatting: yes, the first menu selects the element type for whatever block the user is in. But no documented way to change that menu. - has the many inline formatting buttons (inspired by MS Office) - just one guy with one release. That is unlikely to change with this license. ## [TinyMCE](http://tinymce.moxiecode.com/) LGPL Moxie wants to sell MCImageManager and MCFileManager. [TinyMCPUK](http://p4a.crealabsfoundation.org/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: - a "Formats" menu, which is a list of html element names with no ability to couple with class. It applies to whatever the containing block is, regardless of selection. - a "Styles" menu, which is a list of css class names with no ability to limit by element name. Applies to the selection if there is one (using a span element), otherwise applies to the containing block (determined by "Formats") and eliminates included span styles. To make it ignore the selection, edit tiny_mce_src.js, case "SetStyleInfo", and make it always use the parentElem. - a ["style"](http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/style) plugin. This is for directly editing CSS property values. Review items: - Demo: [examples](http://tinymce.moxiecode.com/example_full.php?example=true) - Plugins: builtin [reference](http://wiki.moxiecode.com/index.php/TinyMCE:Control_reference) as well as [unbundled 3rd party plugins](http://sourceforge.net/tracker/?atid=738747&group_id=103281&func=browse) - Safari: loads, but buttons don't work. [partial working on Safari](http://wiki.moxiecode.com/index.php/TinyMCE:Compatiblity) - Shows path: yes, which can be used to remove containers - Span vs. Block Formatting: sort of, using the Styles menu. - Does toolbar statefulness on links conveniently - [Configuration](http://wiki.moxiecode.com/index.php/TinyMCE:Configuration) is well-documented and easy - supports callbacks for save and [post-cleanup](http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/cleanup_callback) - table editor has no th support; has a complex dialog for creation - URLs: controllable by options: http://wiki.moxiecode.com/index.php/TinyMCE:FAQ ## [Whizzywig](http://www.unverse.net/whizzywig-cross-browser-html-editor.html) MIT license (whizzypic.php and whizzylink.php are GPL). The author wrote a [nice rant](http://www.unverse.net/why-i-wrote-whizzywig.html) (note this says it is GPL'd, but [it isn't](http://www.unverse.net/whizzery/licence-mit.txt)). ofbiz adopted it over tinymce. - Safari: no - performance: faster than others. very small in size. - block vs. inline: does block element selection with hard-coded set (in function makeSelect). The values are passed in directly to the "formatblock" execCommand. You can add your own custom select menus, but those are only for insertion of html, not setting the block wrapper. - state: doesn't show current path, or current element type, or bold/italic state. - extensibility: very easy - has hardcoded buttons when viewing raw html, and puts them below the textarea (function tagButs()) - samples are all invalid html (assuming textarea content model allows markup) - no namespacing on javascript variables ## [WYMeditor](http://www.wymeditor.org/en/) 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: - does not support more than one per page - requires initial content in a div, not a textarea In the current version (v0.3): - Demo: [demo](http://demo.wymeditor.org/demo.html) - Safari: only supports IE and Gecko (not Opera or Safari) - Images: only a very basic image browser - Documentation: [customization](http://trac.wymeditor.org/trac/wiki/0.3/Customization) but it is currently inconsistent with the demo (aEditorCss vs. editorStyles, etc.) - does not show current state of bold/italic - the link/unlink buttons are hard to use (when are you creating/editing? what do you have to select?) - images are stretchable. selecting an image then the image button doesn't let you edit its properties. - the "Paste from Word" makes the untenable assumption that users will popup first and paste into that - has a confusing (to users) distinction between "Containers" and "Classes" (containers are element types; classes are html class attributes specific to each container) - Extensibility: easy if just class attributes and elements - by default calls blockquote a "Citation" - does a good job showing nesting of blocks - images: no graphical image picker ## [YUI](http://developer.yahoo.com/yui/editor/) ## 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: - Has Safari and Opera support - no image picker, just popup asking for URL. Though there is a Flickr picker: http://developer.yahoo.com/yui/examples/editor/flickr_editor.html - does show DOM path in footer - no sign of a way to use classes instead of inline styling - no XHTML support, though does have hooks for server-side filtering ## [Xinha](http://xinha.python-hosting.com/) ## bsd-style license. Originally based on htmlarea. [AreaEdit](http://www.formvista.com/otherprojects/areaedit.html) is a fork of Xinha . Xinha has a fair number of [plugins](http://xinha.python-hosting.com/wiki/Plugins). Some of them in particular are helpful in producing more "semantic" html: - [Stylist](http://xinha.python-hosting.com/wiki/Stylist) However, it is intended to support multiple classes, not just a single one, which makes it harder to use by naive users than the CSS plugin. It puts a multi-select on the right-hand side. It only presents classes appropriate to the context. - [StyleManager](http://xinha.python-hosting.com/ticket/922) Example not working for me. Intended to edit the CSS itself. - [CSS](http://xinha.python-hosting.com/wiki/CSS) applies named css classes to the selection (span formatting) - [DynamicCSS](http://xinha.python-hosting.com/wiki/DynamicCSS) reads styles from a css file like Stylist, but puts them into a drop-down instead. Applies to the selection (span formatting). - [SuperClean](http://xinha.python-hosting.com/wiki/SuperClean) client-side Word cleanup, and server-side cleanup using tidy and php. There are multiple image popups: - the builtin popups and insert\_image.html - no image browsing - [ImageManager](http://xinha.python-hosting.com/wiki/ImageManager) - has directory chooser; upload and browse. Now replaced by ExtendedFileManager. based on the Xiang Wei Zhuo image browser for htmlarea. ImageManager is a quite ugly bit of backend php. seems to screw with relative urls in existing img elements. - [ExtendedFileManager](http://xinha.python-hosting.com/wiki/Plugins/ExtendedFileManager) - slightly different/improved ImageManager; both require embedded to configure php see http://xinha.python-hosting.com/ticket/811 - InsertPicture - exclusively for browsing server-side images Review items: - Demo: [demo](http://xinha.gogo.co.nz/xinha-nightly/examples/ext\_example.html) - Safari: fails completely - Block Formatting: sort of. The "CSS" plugin only does character styles on the selection. The "Stylist" plugin applies classes to the current block, but complicates matters by allowing multiple selection. The "formatblock" menu is for just element types. The "Stylist" plugin is closest, but to simplify things it would need to be changed to a toolbar single-select menu. - Shows Current Path: yes - shows formatting state: yes - return means paragraph: yes, though some documentation claims it does so only if you start the textarea content with an empty <p> # Other Editors ## [WidgEditor](http://www.themaninblue.com/experiment/widgEditor/) GPL. Simple. Fails in Safari. ## [RTE](http://www.kevinroth.com/rte/) originally public domain, now CC, with uncompressed source available only for purchase for $49.95. simple. works in safari. has a [demo](http://www.kevinroth.com/rte/demo.htm) ## [TinyRTE](http://www.alfmiti.net/demo/tinyRTE_demo.htm) 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. ## [TinyRTE](http://tinyrte.outraxx.de/) Unrelated to the other TinyRTE; seems to really be TinyMCE ## [ConceptRTE](http://www.conceptuel.co.uk/conceptRTE/) Another spinoff from Kevin Roth's RTE. Doesn't seem to add much. - Safari: fails ## [Helmi RIA Client](http://public.helmitechnologies.com/trac/) GPL. no demo. no public docs. ## [Loki](http://apps.carleton.edu/opensource/loki/) 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. ## [OpenWysiwyg](http://www.openwebware.com/products/openwysiwyg/demo.shtml) LGPL. 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](http://wiki.bitfluxeditor.org/BXE_2.0) ## Kupu 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](http://johnnydebris.net/kupu_nightly/kupu/common/kupu.cgi) 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/ # Who is Using What # \[This section not updated since 2005\] Typepad has announced "rich text editing": http://typepad.com/resources/2004/11/rich_text_editi.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.