Thursday, May 21, 2009

A comparison of major open source javascript WYSIWYG HTML editors

This post is about comparing open source javascript based WYSIWYG (what you see is what you get) HTML editors, which run in the browser. People who are not intimately familiar with the inner workings of html and css need them. They'll usually look something like this (which is the wysiwyg editor :)

These editors are often referred to as rich text editors (RTE), what they'll do is convert a regular html textarea element into a word processor. Sort of.

There's some magic involved: They'll grab the content of the textarea, create an iframe, put the content in there and turn on designMode in the iframe. The content can then be modified. Read more about it here.

But because different browsers handle things differently, a good JS editor has to deal with all bugs and ways a browser creates markup, so (cross platform) compatibility counts. Also it the output created by the RTE shouldn't vary from browser to browser.

Furthermore it has to be extensible without hacking it, localizable, and customizable. Good documentation is a must as is a clean and open source code base.

I'm also looking media integration, as this is a request i see a lot.

I looked around and found this site where a lot of editors are compared, but it's not quite up to date. Here is another one. And another. So i figured, I'll take a new look at some of those editors. Mostly the ones I have worked with before and which are being talked about enough. Here's my selection (it seems like it matches wikipedia's list) in alphabetical order:

  • FCKeditor
  • Dijit Editor (dojo toolkit)
  • Kupu
  • Tiny MCE
  • YUI Editor
  • Xinha (former HTMLArea)

I want to start out with a list of things they all have in common:

  • Open source license like GPL, LGPL, BSD Style ...
  • Configurable toolbar of available html/css elements, for example: link, strong / bold, italics, underline, font-size, font-family, ordered and unordered list, blockquote, align, indent, img, etc.
  • Ability to provide your own plugins
  • Skins


It's rock solid and it has the ability to create almost all html entities you can think of, even though i don't see how inserting a form element is all that necessary, which can be disabled of course. It's got everything, h1-h6, pre, code, sub- and superscript... You can even insert a div and choose a css class from a list or enter your own. I18N? You got it.

What I really like is how you can use the integrated file browser, if a server side connector is available, sample code is included. Editing in "full-screen-mode" is possible.

Here's a small thing a don't like so much: If you want to modify a dialogue, for example the "create link" dialogue, which might be necessary to allow easier access to site-internal links, you'll have to hack the corresponding html and js files. While this might be acceptable, it's not clean as changes will be lost in a subsequent updates and it cannot be shared as easily as a plugin can.

As I understand, it's currently being rewritten to allow exactly that kind of interaction with the dialogs, the next major version will
be called CKEditor.

Dijit Editor

This light weight editor is part of the dijit widget library of the dojo framework. It's very basic, but nice to have if you're already using dojo. Apart from that it's not a good choice. There is little documentation, but none as to how to create or modify existing plugins. No one seems to be writing plugins for it, also it uses block quote for indention, which is semantically incorrect and the html it creates isn't very good what paragraphs and breaks are concerned. The worst part it the limited set and configurability of html elements in the toolbar, there's not even the image tag. I mean common!


Kupu is centred around the idea of making the whole document (page) editable, so it provides means to edit more than just the html. Testing it proved harder than I would have thought, but I figured I should give it a try, since it's the highly integrated rich text editor for Plone, a CMS of which I think highly. I gotta say though, i hate it when there's so little documentation. I ended up looking at how it is used in Plone, which is awesome, no doubt about it, BUT using it on my own project: not a chance. Still very interesting.

Tiny MCE

It's very much like FCKeditor, except there's even more options. Editing inline CSS: not a problem. Plays well with tables: yes. Is the default for wordpress: yes. I18N: sure. It really seems to be quite popular as you can see here (a long list of content management systems) and it's well documented. There's a company called Moxiecode which continuous to develop it, which is good, because they take good care of the code. But that also means they have a financial interest and since it's open source, well, they can't charge you for using it. But they can charge you for plugins, they have created: 50 € for a file manager or 32 € for an image manager. I haven't tried these, but I'm sure, they'll get the job done. It's not a bad monetization strategy either, create a good free product, get lots of users and sell quality plugins.

What extending a dialog is concerned, the same that goes for FCKeditor also goes for TinyMCE, mucking about in the source is required.

YUI Editor

Honestly, this editor just blows my mind. It's so well structured, it's backed by a big company (Yahoo!) with true open source ambitions. There's a vivid community and a huge collection of example code and plugins available. I18N and documentation: Yes, sir. The YUI Editor is part of the YUI JavaScript Library, which is a modular collection of tools for building rich internet applications (RIA) or for simply adding a little functionality to a website. The editor is pretty sweet, but doesn't have all the bells and whistles the FCKeditor or the TinyMCE provide. But you can teach him :D

What I like about extending it, is how easy that is, and how you can can literally hop in at any point and change what it does or how it looks. The way it works is that events are fired when a button is pressed or a dialogue is opened. You can then hook into that event and do your thing. Also everything is build from script, so no need to worry about changing static templates, it's all dynamically created.


I was looking into this editor, because its predecessor (HTMLArea) is the standard RTE in Typo3, a fairly popular CMS, at least in Germany. It's got tons of buttons, a lot like FCKeditor, some more esoteric ones for formula creation or even music notation... It seems to have a nice file manager integrated. What it lacks is documentation on how to write your own plugin. It also doesn't seem to have a lot of user or developers. I wonder if it'll be the RTE of the Typo3 5.0, my guess would be "no", but you never know. I know that it hasn't gained enough traction yet to use in long term project.


There are lots of javascript rich text editors out there, i haven't even looked at the commercial ones. Most are pretty useless as they aren't cross browser compatible or outdated or have no documentation... I tried to look into the most active and promising ones that met my cross browser and open source criteria and found significant differences in capabilities and configurability.

For now FCKEditor and TinyMCE aren't a bad choice, as they provide a very large array of buttons, while still being configurable. If you're going for customisation of features or if you're looking for ways to enhance or change the existing dialogues of the editor you should go for the YUI editor.

One more thing though: Even if YUI might be nicer to enhance and it's all shiny and new, it still might be a better choice to go with the editor that a given blog engine comes with or that the cms of choice has highly integrated.


My impression is that the upcoming CKEditor is definitely something to be on the lookout for, as it implements some nice features.

Once the third generation of the YUI suite is out, it'll be even more interesting, YUI 3 will provide jQuery like selector expressions, and I think it's a chance to soley rely on one JS lib, because if you use multiple libraries and / or editors they will inevidably duplicate functionality and thus costs more bandwidth. But that's a different story.

No comments: