Thursday, September 3rd, 2009

CKEditor 3

Category: JavaScript, Library

Frederico Caldeira Knabben is the creator of the editor formerly known as FCKEditor. His latest update changes the name to be less controversial, and delivers a lot more than that.

CKEditor 3 has been cleaned up a ton and you will happy to see the main focus:

Amazing performance!

Yeah… that’s really a big difference. CKEditor is fast to load and fast to use. Our development team stayed focused to bring here the best performance you can have, using all modern best practices. You’ll be amazed with it.


Another important aspect on totally rewriting the code is that CKEditor is now fully accessible. It’s totally screen reader compatible and keyboard only usable. It complies with the W3C WCAG and the US Section 508 accessibility standards. It also offers a unique high contrast feature. CKEditor is here for everybody.

Brand new UI

You’ll note that we have also a brand new UI based on the Kama skin. Other than modern, Kama is colorful like a chameleon, so you can precisely match its color to your needs. This is an innovative and unique feature you’ll find in CKEditor only.

New JavaScript API

The CKEditor code is also much different now. It’s up to date with the new JavaScript development requirements, offering a rich and powerful integration and interaction API. The editor is totally plugin based, and it can be extended and modified in all senses to fit all needs.

Much more…

There are definitely lots of new things in CKEditor. This page would not be enough to list them, so take a ride on it and try out our demo. Then, download CKEditor and start integrating it today in your next generation applications.

Posted by Dion Almaer at 6:59 am

4.5 rating from 50 votes


Comments feed TrackBack URI

Pretty but at over 300k (before decompression) not including CSS code and library dependents, I think I will pass on all these wysiwig editors. At least this one doesn’t have the nerve to call itself “tiny”.

Comment by ck2 — September 3, 2009

Are you kidding? Most web sites’ home page logos are bigger than 300K.

This is gorgeous, responsive, fast, and full of features. Excellent work!

Comment by sentientholon — September 3, 2009

@ck2: I understand your concerns about it, but really… there is no magic here. If you want to have features, quality and compatibility, you need code. This is actually a normal situation in modern js apps, and the rule “the best is the smaller” is not applicable really.

We have really spend a lot of time, and focused our development on performance; specially loading performance. We have implemented several solutions to make things as fast as possible here, and the results are definitely good. I hope our demo can prove it. So, it doesn’t look like we’re doing that bad in this sense.

Then of course, we really hope that the CKEditor benefits compensate anything else.

Comment by fredck2 — September 3, 2009

@ck2: sometimes you have to include a WYSIWYG editor for your clients — say a custom CMS or some back-end editing. This is one of the most feature-rich, well-built, web-based WYSIWYG editors you can get.

@fredck2: I built a WYSIWYG editor as a jQuery plug-in a year ago, and have massive respect for what you’ve done with (F)CKEditor. Adding buttons for simple formatting (bold, italic, et al.) is dead easy, but making such a complete WYSIWYG editor is no small feat. The entity conversion is awesome, and the fact that Cmd + Left Arrow doesn’t bubble up and drive the user back a page are both great examples of (F)CKEditor’s awesomeness.

Comment by MichaelThompson — September 3, 2009

Would CKEditor be any smaller bytewise if it was rewritten such that it could be stand alone *or* library based? i.e. rather than implementing its own DOM code it would rely on jQuery or YUI or moo or dojo or whatever library instead.

Comment by zachstronaut — September 3, 2009

I’ve yet to see a WYSIWYG editor that I would actually want to use, other than the one in vBulletin.

And it’s 53 KB before GZipping.

Comment by Darkimmortal — September 3, 2009

Looks really nice. We’re developing a large Javascript application at my company that uses another open source editor internally. Unfortunately, all available editors (commercial and otherwise) are really intended as drop in replacements for textareas. We really want to do something like elem.contentEditable = true, and bind editing to arbitrary divs and spans.

One thing we contemplated was creating a generic RTE library that we could use in our app and could be used to build things like editor plugins for various libraries – a sort of sizzle approach. But as anyone will tell you, these things are incredibly complicated.

CKEditor certainly looks like a promising alternative to what we’re currently using – wish the docs were a little more complete, but I’m used to digging in deep. :)

Comment by erikharrison — September 3, 2009

I prefer »what you see is what you mean« editors. Eg. Would love to see it progress faster. It’s a great idea!

Comment by sandstrom — September 3, 2009

I’m guessing its too late for this to be rolled into CF9’s built in FCKEditor usage…

Comment by jonhartmann — September 3, 2009

Having spent an absurd amount of time developing a solid (and very limited) WYSIWYG editor targeting only WebKit, I am frankly astonished at how good CKEditor has gotten. People who haven’t developed these may not realize just how many browser behaviors must be accounted for, overcome, worked around or otherwise dealt with to get a solid editor that’s not going to spit out the most atrocious tag soup.

As far as size, I personally think that the default size is problematic, and ought to be accounted for with modular builds. That said, it’s open-source. In fact, if I can get enough time to set aside, I may very well try to contribute that myself, as I would directly benefit by being able to build a much more compact and minimal-feature editor.

Thanks CKEditor devs, it’s a treat to see rich editing getting better on the web.

Comment by eyelidlessness — September 3, 2009

To the devs: I found a bug in the handling of shift+enter (single line breaks). At least in WebKit, a single break fails to show up, and a second break is necessary. Using the Web Inspector, what I’m seeing is that a br tag is entered, but the cursor is placed before the br tag and the tag itself is collapsed as there is no character data past it within the parent.

I worked around this bug in my own editor by placing a temporary bit of whitespace after the br tag, then destroying it when any character is entered on the new line. Hope that helps!

Comment by eyelidlessness — September 3, 2009

My experiences:

* I always need an integrated file/image uploader — since these aren’t pure JS but require some server-side action I know that maybe it can’t be a pure part of these WYSIWYG editors, but… It’s a big pain to find available plugins, configure them, etc. (Plug-in config files are always separate and buried so it is hard to move the thing from system to system. And the plugin don’t stay synched with updates.) FCK and TinyMCE both try to upsell this feature as a paid add-on. PITA.

* I always use this as part of a backend, since exposing it to users opens you up to code injections, but my (never tech-savvy) clients always paste MS Word formatted stuff in there which is always mangled. What’s needed is a MS Word purifier, that strips FONT stuff, strips the bad HTML, but leaves (or replaces) B I, and other basic formatting. The “paste from Word” feature removes all formatting.

All-in-all, indispensable. Thank you Frederico Caldeira Knabben!

Comment by jamienk — September 3, 2009

Sounds very interesting what you are building, are you perhaps building an application that has a editor like the one in this video:

With techniques like the ones described here:

Erik, I would love to hear more about your project. You can reach me at

Comment by ebdrup — September 3, 2009

Hmm, why CKEditor instead of umm, maybe, Freditor, for Frederico Editor?

Comment by GordonStanton — September 4, 2009

I have been a long time user of FCKeditor, and am quite distressed with the direction the CKEditor team is taking.

Generating Valid HTML code does not seam to be a priority at all for them.

A clear example of this is in the flash plug in. You now have the ability to set the “hspace” and “vspace” property on the object tag.. Not a good direction. Its not valid HTML.

Also there is no support for flash vars…

I have been using an alternate flash plug in by Alfonso Martînez, ( ) that embeds flash using the swfobject js, so it produces valid code. It supports flash vars and has a config option for setting a div “wrapper” around the flash object. You can set margin in that wrapper div using valid CSS instead of the wrong approach of Vspace and hspace that the 3.0 team is taking..

Comment by Aduffy — September 4, 2009

I have to say that I love this. I’ve been using the FCKEditor for years now and the one thing that many client’s say to me is how easy they find it to use.

They don’t care about waiting a few extra seconds for it to load, especially when they can paste from Word and end up with something that doesn’t look awful on the front end ;)

Great work Frederico + team, keep it up!

Comment by RichardReddy — September 6, 2009

I’ve just published details about the loading performance of CKEditor:

I hope this can clarify any doubt about it.

Comment by fredck2 — October 13, 2009

I’ve just moved over from tiny mce and am liking ckeditor. However I wish the pop up dialogues for editing images, tables etc had nicer HTML code for styling as it can be tricky.

Comment by BWRic — October 23, 2009

I’m the author of the old FCKEditor plugin and I’ve just released a new jQuery plugin for integration with CKEditor:

It’s pretty basic at the moment. It can create editors like this:
$(‘textarea’).ckeditor({ path: ‘/path/to/ckeditor/’ });

And it takes care of updating the element’s value (with the latest output from CKEditor) so it’s ready for ajax submissions.

Comment by spinal007 — November 25, 2009

Leave a comment

You must be logged in to post a comment.