5 Open Source Rich Text Editors
August 14th, 2007Here are 5 open source WYSIWYG editors you might consider for your upcoming development projects. Rich Text Editors are one of the workhorses of modern web applications. Providing simplified wysiwyg formating of content for forms, RTEs have become a favorite among users.
Tiny MCE
Tiny MCE stands out as the most popular of the modern editors. The high flexibility, simplified theming and extreme ease of use the editor provides are highly regarded and well praised. Some key features:
- Microsoft Word Cleanup Filter
- Ability to fine tune available buttons
- Ability to restrict html to certain css styles
- Excellent Media import tools
- Simple API for custom features
- Skinable
Xinha
A venerable successor to HTMLArea, Xinha combines flexibility with a slick interface. Although once relegated primarily to the Zope / Plone universe. Xinha has lately emerged as a powerful stand alone editor. Many developers prefer its media & css tools to those of Tiny MCE
- Microsoft Word Cleanup Filter
- Highly Configurable
- Ability to restrict html to certain css styles
- Powerful Media import tools
- Skinable
FCK Editor
Although still popular, FCK editor doesn’t compete as well against the top tier wysiwyg editors as it once did. The interface seems clunky, especially compared to Xinha or Tiny MCE. And there’s always the issue of the name, I’ve had it shot down from a project spec because of it. The software is included here out of completeness and the fact that it is still widely used and adopted.
- Extensive capabilities
- Established & heavily deployed
Dojo Editor Widget
The Dojo Editor Widget is an integral part of the Dojo Ajax Toolkit. It is included here because of the compelling features that make it unique. Chief among these features is the ability to share one toolbar across multiple editor instances. It is this ability to provide a traditional application toolbar feel when multiple editors are in use that sets the Dojo Editor apart and inspired me to include it here today.
- Skinable
- Shared Toolbar Support
- Powerful API
YUI Rich Text Editor
Finally, an editor that works in Safari. Built on the YUI toolkit, the beta form of the Yahoo Rich Text Editor was designed from the ground up to work in Safari. By coding for Safari first and then modifying the code to create something that worked in Opera, Firefox & Internet Explorer. Dav Glass created a cross platform editor that surpasses every other editor in this list for browser support. The other unique feature of the YUI editor is web 2.0 / Mashup support and integration. By integrating a unique Flickr photo picker & useful insert link tools the YUI RTE has emerged as a force to be reckoned with in the WYSIWYG world.
- Flickr Photo Picker
- Link Picker Tools
- Powerful API
- Skinable
- Safari Support
Previous Post 
Next Post 
Latest Posts
26 Comments
October 19th, 2007 at 12:30 pm
Great post! Where did you get that massive TinyMCE theme? I’m jealous.
October 19th, 2007 at 1:05 pm
That’s the default TinyMCE with everything turned on. I don’t recommend using it in most cases but it’s nice to see everything available. You can see it in use at: http://tinymce.moxiecode.com/example_full.php?example=true
Hope this helps,
-Don
October 24th, 2007 at 12:26 pm
Thank you so much, Don. I ended up using it as my starting point and widdled my way down to a version *almost* as basic as the simple theme.
Any experience with changing the XHTML validation? I opted for the full set (which is looong) but didn’t notice that much of a lag on the data I was testing with.
October 24th, 2007 at 1:17 pm
I’ve never noticed that much of a lag with validation. I have however had bad experiences with validation double escaping things when I plug it into a CMS. Basically, I’d leave it with full validation provided you have full control of the server side processing. If you rely on 3rd party software for that, things can and do go wrong.
October 24th, 2007 at 1:21 pm
Good to know. Thankfully, we do have full control of the CMS. Thanks for the heads up!
Regards,
Ian
October 24th, 2007 at 1:22 pm
Sorry, I was a little vague. On a recent project I was implementing a Blog on top of an existing CMS. There was a conflict between the TinyMCE validation and a second set of validation that took place in the CMS that caused all of my special characters to be rendered as double escaped. Since it’s a good idea to handle validation on the server as opposed to the client any way and Tiny MCE doesn’t really do anything on Safari. I’ve switched to relying on server side validation for much of this data.
October 24th, 2007 at 1:27 pm
Agreed. So you’re just using *[*] in your valid_elements config setting?
October 24th, 2007 at 1:37 pm
I still can’t tolerate font tags, I wound up with the default rule set with <font> removed & an extra parsing layer on the server to remove double escapes.
October 24th, 2007 at 2:19 pm
Nice. Thanks again for sharing your experience.
If you’re ever in the DC/MD/VA area, I owe you a drink of your choosing (beer, wine, coffee, whatever).
Thanks again.
October 24th, 2007 at 2:33 pm
No need, although a plug on your blog would be greatly appreciated. Good luck with the project BTW.
October 24th, 2007 at 2:46 pm
[…] comparing them with each other, I simply searched for a comparison itself. Don Albrecht wrote up a nice comparison, which helped us pick TinyMCE as the clear winner. Not only did his comparison save me a day or […]
April 23rd, 2008 at 12:20 pm
Hey, I was just wonder which of these editors would be the BEST all around to use. I develop using Ruby on Rails.
I’m having some trouble right now with tiny_MCE. I don’t need it to save with these tags:
Untitled document
And I was wondering if the document-wide font (stored in body tag) could be stored in a span tag interlining the body?
April 23rd, 2008 at 12:26 pm
generally speaking, the best to use all around is tinyMCE. It offers the best current set of features and extensibility.
You can tweak the tinyMCE filtering on tags. As for your third question, I’m not sure what you are asking. You probably shouldn’t store a document wide font on a tag and should load it via CSS instead.
April 23rd, 2008 at 12:31 pm
If you have heard of the ‘fullscreen’ plugin, you can set properties of the document you are creating. Main option I’m interested in is the font-family and font-size.
I’ve noticed that this option is set in the body tags. What I was wondering is can I omit the above listed tags, but make the body options (font stuff) store in a span around the entire bundle of text.
Basically, I need this to create individual paragraphs and I want to add them together in the end.
If you have used the ‘fullscreen’ plugin, I have another question:
Why when I set this font stuff, and click update, the editor still looks like it has tiny font, but once saved, it renders with the right size?
April 23rd, 2008 at 12:32 pm
…and how can I filter these tags:
and
April 23rd, 2008 at 12:33 pm
Okay, these tags:
!DOCTYPE…
html
title
body
April 23rd, 2008 at 12:44 pm
I’m not sure fullpage is the right approach in this case. Wouldn’t it make more sense to use the traditional approach and then “wrap” the resulting html with the page declaration on the backend?
It looks like you’re basically doing this already by wanting to throw out the doctype, html, title & body tags (I’m assuming you’d probably want to throw out head too).
April 23rd, 2008 at 12:49 pm
Have you looked at “Valid Elements” & “Valid Child Elements”? That may get you what you want as well.
April 23rd, 2008 at 12:57 pm
Sorry, one last question:
I can set the font and font-size in the toolbar, but when I hit enter, it forgets all that information? Is there a way to fix this, because that would be ideal.
April 23rd, 2008 at 1:19 pm
I’m not sure,
Where are you hitting enter? In the body of the editor? It shouldn’t loose all of the setting information unless it’s automatically closing a span or div.
April 23rd, 2008 at 3:51 pm
Here’s the problem:
I want to be able to set the font in the document. (preferably in the toolbar)…But if I set the font information in the toolbar, when I hit enter inside the editor (new paragraph), the cursor goes down, but all the formatting is lost.
I’m wondering if you know how to make it keep toolbar formatting from one paragraph to the next?
April 23rd, 2008 at 3:54 pm
Not sure you can do that. I would suggest handling this via CSS if possible / enforcing a nested dom with the child elements.
May 28th, 2008 at 3:56 am
Don,
Do you have any experience with NicEdit ? (Nicedit.com) We are looking for something that’s definitely Safari compatible, but is just simple to use. Tabs, fontsize, fonttype that’s about it. He just doesn’t write anywhere whether the thing is Safari compatible or not, but the advantage is that it’s only a 30 K javascript, which for basic forms or entering info of “my profile” or something is quite sufficient.
Any comments would be quite welcome.
June 4th, 2008 at 8:33 am
Hi
you stated here that DOJO supports one tollbar for multiple editable area’s.
i couldn’t find any support to your claim. do you have an example of this?
Thank you
July 24th, 2008 at 10:28 am
Hi,
I’m having a problem with tiny_mce.
In the examples, when you return twice,   is inserted.
My problem is when I return twice, instead of the above, my content ends with and open p tag () and all content that was after the double return is not saved. Please help, I haven’t been able to find an answer.
August 3rd, 2008 at 6:28 pm
Which version of TinyMCE are you using?
Leave a Reply