wysiwyg editors in web content management

I am slowly making up a set of blog posts about the components of content management systems, starting with the earlier one on content repositories. Coming up next will probably be templating systems.

In the beginning the web was editable in the browser. Tim Berners Lee made it so. But this did not last for long. Eventually Microsoft restored this, to some extent, with the contentEditable properties and related Javascript interfaces. Now these have a lot of foibles, and the current HTML5 standardization has not done a huge amount of work here yet, certainly not adding new features or changing the basic interface substantially, so a lot of behaviour is currently underdefined, which makes cross browser compatibility more difficult. While the main desktop browsers all implement the interface, mobile ones do not in general yet, even on form fators such as the iPad, which could very well be an effective content editing device.

Should you use one at all?

Almost every CMS supports wysywig HTML editing, but it is not entirely clear how much they are used. To be quite blunt, they have always been among the worst editing environments ever devised, overlaid with a poor HTML model and a tendency towards presentational markup. Most users do their editing elsewhere, at least for originating content. I think though that we are at the point where this can be improved.

The first thing is to kill the presentational markup, and instead support customised semantic use of classes. On the basic level this is easy to implement; there is probably more work to easily support more advanced HTML templates, for example to mark up recipes or other specialist content in consistent semantic ways through this type of interface. Pluggable schema guidance might be needed for this.

The second is to make the editors themselves sane. First step is of course local offline HTML5 storage, so that drafts are still there if you wander off, your computer runs out if battery or whatever. Then just make them nicer to use, keyboard friendly and so on.

Then there is the concurrency question, you may want to show concurrent editing, and the versioning model that applies. This does not have to be the Google Wave style simultaneous editng, although that is one option. People may be editing content for release in different versions.

Import from other editors is of course still important, and making it as painless as possible for the common tools is of course important.

Also, remember it is an editor, people like a choice of editors, so loosely couple it, make it standalone and easily changed.

What not to use

Old school implementations, with nothing now to recommend them that I can see; often they seem to need server side components too, which should not be required now when pure Javascript solutions should be sufficient.

  1. Open Wysiwyg

    Not off to a good start here as the demo does not work in Chrome, works in Opera and Firefox. I guess it is not really in development then. Does not create paragraphs by default, just uses <br>. Still believes in web safe colours and fonts. A classic example of the old school, but not up to date. Open source.

  2. CKEditor

    Much more promising demo, . Paragraphs are real (uses a &nbsp for blank ones, which is I suppose ok), there is a paragraph style dropdown that manages paragraphs, headings and divs. The style dropdown is a bit disappointing as it sets styles not classes, and you can still set fonts and so on. Works in Chrome, Firefox and Opera. The old school done right. Open source.

  3. TinyMCE

    Ah yes, the classic one. Feature set similar to CKEditor, in taht it treats paragraphs the same, has a dropdown with predefined styles, that are style tags not classes. Seems a bit clunky and flaky in comparison, and has odd terminology, since when has a div been a layer? Both have a smiley insertion feature that suggests that people have been wasting time on pointless stuff rather than reconsidering how these programs should work. Open source.

  4. XStandard

    Good blurb about supporting CSS properly and the importance of markup and presentation separation, but in a bout of massive fail there is no demo on the website. Your reviewer has no intention of installing it to test it, especially as it does not support Linux as a platform in a second fail. Commercial.

  5. InnovaStudio

    No demo either, apart from animated screenshots. Why are these commercial companies so full of fail? Web 2.0 products with no web trial? Seems obsessively to be about dimensions and fonts from the features list, not about separation of concerns.

  6. ActiveEdit

    ActiveX DHTML with Java fallback for other platforms. Need I say more? Commercial.

  7. contentEditable

    Well at least here the demo is the homepage. All inline with a simple-ish mechanism to mark blocks as editable. Stupidly though, while it appears to be non modal, all the menus are modal popups, which completely destroys the usability.

  8. widgEditor

    Very simple editor. Adds divs not paragraphs around everything. Open source.

Good implementations

Largely based on contentEditable, fixing up the inconsistencies, although Dijit is based on the less flexible designMode which means it has to run in an iFrame.

  1. YUI editor

    Note there is also a YUI 2 version. In many ways the demo is not much use, as of course this is part of the YUI framework and needs some Javscript infrastructure to customise it effectively. There is also a YUI2 version demo, and linked demos of plugins. Much better than anything above. Open source. Iframe based for compatibility with the grade A browsers.

  2. Dijit

    This is the editor that comes with the Dojo widget set. Still iframe based, not a full contentEditable implementation.

  3. Aloha

    Some nice demos available, indeed probably the best demo site of any editor. Aims to fix up the issues and cross browser quirks contentEditable, and looks nice too. Open Source.

Other ways 1: Canvas

A survey of what is up is not complete without mentioning Skywriter, which is a (code) editor written entirely in canvas. As far as I can see this is an utterly pointless approach long run. It is especially a bad idea for HTML, where fitting in with the CSS of the page matters, so lets ignore this.

Other ways 2: pure Javascript

You can in principle implement the whole of a contentEditable-like editor in pure Javascript, using a little div as a cursor and everything, no help at all from the browser. That is a lot of work, of course. I know of two implementations, one being the 2010 release of Google Docs, which explains why the did that, in order to be able to provide the best cross browser support. The other implementation I know of is the one for Squiz CMS, no online demo, not open source and tied into one product. This is pretty functional although it had some browser compatibility issues last time I used it, and ther website still says it does not support Webkit.

Other ways 3: Markdown and Wiki markup

I have to say I use Markdown a lot, this blog is generally written in it. There are two issues I see. One is that it is limited, and while you can add native HTML, this often means everything has to be redone in HTML (trying to add anchors to a list for example). There are extensions with more features, but then you get into compatibility issues. ALso there is no sanely reversible transformation that will generate the sme output as there are notational choices, so it is generally best to keep the content in Markdown all the way through. There are much the same issues with Wiki markup, although it is extensible too, which causes more issues of trying to remember constructs, and compatibility is weakened. The difficulty is that HTML is not a very good markup for humans to write, but once you get past the very restricted domain that say Markdown handles, producing something that works well is hard, maybe impossible.

Other ways 4: Don’t use HTML

A number of people I have worked with, and some content management systems go with a very minimalist use of HTML, pretty much text is paragraphs, everything else is structured fields. A slightly enhanced version of this, effectively a very minimalist tiny markup, corresponding to even less than Markdown is the COPE system.

Personally I believe we need to expand the use of rich text, for many use cases “just the words” is not enough, and we need equations, images, notes, asides, sidebars, tables, captions, and all the richness of rich text, so I don’t think this is viable for much serious writing, and we need to expand from the dumbed down web that this enforces.


While the wysiwyg editor as it has been in content management systems is pretty awful, I think we need to expand the principle and try to do better, go back to the really editable web, and support well structured semantic HTML in rich ways, not forms and simple text boxes. There is a lot to do to get this working though still.

No Trackbacks

You can leave a trackback using this URL: http://blog.technologyofcontent.com/2011/01/wysiwyg-editors-in-web-content-management/trackback/


  1. PaulGeraghty

    Nice write up Justin, but you do not mention the possible use of wysiwyg editors as being the front end tools to allow semantic content markup and (LOD) linking.

    In this regard I assume you follow the #IKS_Project’s work with Aloha – some of their efforts being focused on doubling it up as being a possible front-end to an Apache stack – the “semantic rich text editor”.

    Is this because you do not feel this will appear, or is because it is outside the scope of your post?

    (ps I liked your 2011 predictions too)

    Posted January 4, 2011 at 15:24 | Permalink
  2. Thats one of the kinds of things I was thinking of with support for richer markup whether it is recipes or microformats or RDFa the tooling is similar. I think I may spend some more time on Aloha so may do a followup on some more of that.

    Posted January 4, 2011 at 15:37 | Permalink
  3. Clearly an in-depth review. Unbelievable what technology solutions have been build to combine clean markup and the user’s wysiwyg desire.

    We at WordonWiki feel that we completely need to cater the user’s ambition for easy editing. So why not offer the super editor MSWord to create and edit wiki pages.

    We know about the garbage html it generates and its complete ignorance of semantic content. But please think for the moment about the dramatically lowered threshold. If more people contribute content, surely that must be a good thing. — Roland

    Posted January 4, 2011 at 21:54 | Permalink
  4. PaulGeraghty

    In the area of adding semantics to markup here is another that you might want to keep an eye on, Trice. http://bnode.org/blog/2010/05/01/trice-semantic-richtext-editor

    Posted January 5, 2011 at 15:35 | Permalink
  5. James Chalmers

    Nice one.

    Posted January 7, 2011 at 15:27 | Permalink
  6. Interesting post.

    Did you author it in WordPress or a text editor?

    Posted January 8, 2011 at 17:20 | Permalink
  7. Some more I found:

    https://github.com/akzhan/jwysiwyg iframe based, jquery. http://markitup.jaysalvat.com/home/ wiki syntax or markdown, textile, not wysiwyg http://nicedit.com/ http://www.upian.com/upiansource/ueditor/en http://www.wymeditor.org/ not a wysiwyg editor, but semantic XHTML

    Posted January 14, 2011 at 16:07 | Permalink
  8. Andy

    Awesome writeup Justin. Here’s another wysiwyg website editor I found. It’s called Ambid Update. It’s not downloadable, but for people uninterested in messing with code and installing, they’ll let u edit your site from your browser

    Posted April 2, 2011 at 00:26 | Permalink

Post a Comment

Your email is never shared. Required fields are marked *