Skip to content

Instantly share code, notes, and snippets.

Created October 7, 2013 23:00
Show Gist options
  • Save Reinmar/6876464 to your computer and use it in GitHub Desktop.
Save Reinmar/6876464 to your computer and use it in GitHub Desktop.

TL;DR I'm a CKEditor core dev, I watched in which CKEditor was mentioned, I'm sad now.

Disclaimer: I am a CKEditor core developer since January 2012, so I've been working nearly exclusively with contenteditable for almost two years. That made me an expert in some of fields that WYSIWYG editor deals with and gave me a decent knowledge about the rest. Although, my opinion may be biased.

I watched the video from "contenteditable: Roll for sanity" presentation by Garann Means with great interest. The contenteditable feature is a base for all WYSIWYG editors (except those with completely custom rendering system like Google Docs), but is not popular and most web developers have no idea about such thing (what on the other hand does not surprise me). What's more, those who stumble upon it quite often fall into the standard trap:

Hey, we just met and this is crazy, but we've got few hours so let's create a new WYSIWYG editor maybe!

This approach to web development pretty often results in at least decent solutions, but in this case... in complete mess.

Anyway, it was one of the points of the talk, that working with contenteditable is not as easy as it may look like. What I can say from my experience is that Garann only touched a tip of an iceberg. I would say that it was less than 5% of what a decent WYSIWYG editor has to deal with. (Actually, I wanted to write 1%, but I thought that it might look silly.) Also, note that dropping support for older browsers won't help you.

What struck me though, was Garann's attitude to CKEditor and TinyMCE. I would really like to hear what makes CKEditor so awful, because as far as I saw CKEditor actually fixes all (or most) of the issues with native contenteditable mentioned in the talk (and 90% of those beneath the see level). Don't think that my CKEditor core dev's ego was hurt - I really used to hear such comments (although, they are much less common recently). But in this case, when native contenteditable was shown as a insanely tough opponent, I really don't get the reasoning.

There was, however, one argument I can comment on. TinyMCE was mentioned as not so tiny (and CKEditor isn't so tiny too). But few slides earlier Garann showed a code which (as far as I understood, because the quality of video was poor) just wraps selection with a given element (?). This code is neither trivial, nor short, nor, I assume, complete and battle tested. Now, add a method which removes the style from given range, another one that checks if the style is already applied on the given selection and make all this somehow configurable (so different type of styles can be applied). You'll end up with at least 1kLOC (in fact it's a lot more, because another few thousand are reused from other components) in just this one feature. Now add remaining features and don't be surprised when you reach >40kLOC (there's 38kLOC of JS in the basic CKEditor package) when building a basic editor with just bold, italic, lists, links, fixed enter key, pasting, undo/redo and other fundamental functions.

To sum up - if you want to create your own, simple, jQuery based WYSIWYG editor, make sure you have a sufficient supply of antidepressants and patient boss.

Piotrek Koszulinski, @reinmarpl

Copy link

spocke commented Oct 8, 2013

Yes, people think they can wrap up a rich text editor in a day using contentEditable and execCommand. Making a rich text editor small isn't possible not until every browser starts behaving the same way and I don't think that's going to happen any time soon.

I guess both our teams have seen so called "My editor is way smaller and better than bloated CKEditor/TinyMCE". But these editors come and go. Why? Probably because they soon realize how buggy the built in functionality is and how many years it would take to work around them. I mean our two companies have been working on this problem for 10 years and we are still not finished it's a damned hard problem.

I'm also some what somewhat feed up with this constant bashing of our editors. It's ok with constructive criticism but each time I ask people ok if our editor is horrible whats wrong with it they can't answer me. I guess the problem here is that everyone want different results from a HTML editor and we will never be able to produce the perfect output for everyone since there are as many styles to HTML output as there is web developers.

Anyway, keep up the good work. TinyMCE & CKEditor is the only options for serious content authors anyway.

Copy link

garann commented Oct 8, 2013

@Reinmar - Man, I'm sorry. I did a thing I hate, which was to flippantly disparage someone else's work. I'm sorry. The background is this: a long time before you began working on CKEditor (according to your gist), I had to use FCKEditor in a freelance project. We needed only incredibly simple features, things that a developer could have reasonably whipped up using even the fragmented implementations of contenteditable available at that point. So we didn't need most of the tools it provided. Additionally, the clients wanted its look and feel completely changed. I got almost all of the changes implemented, but there was one - I forget what - that was impossible to override through the API, and was built in such a way that I would have to have rewritten a large chunk of the core code. I pushed back on that single requirement, the clients threatened to sue, there was a large deal of back-and-forth, and we parted ways without my partner and I being paid for a large amount of work.

That's obviously not FCKEditor's fault, and certainly not CKEditor's, but it is one of those ridiculous scenarios that remind you that the things that lead a developer to reinvent the wheel tend not to be reasonable things.

However, I think you have a bit of bias with regard to dealing with contenteditable. While CKEditor is definitely less heavy than its predecessor, the fact remains that it's a widget, not a library. It's not something that can be easily built on top of. And sometimes people need to use contenteditable without the same set of assumptions contained in your product. I'd love to see you and your team abstract out your utilities for dealing with contenteditable into an open source library other devs could contribute to, rather than constantly reinventing the wheel, and I think it would be a huge asset to our community. Providing a way for people to easily solve this problem could even end up being the push browser vendors need to solidify their implementations, which would be magical.

Copy link

Reinmar commented May 7, 2014

Wow... I've just accidentally stumbled upon this gist and noticed that you replied. I thought that Github will notify me about that. Apologizes for the 7 months delay :|

Anyway, thanks to both of you for replying. There's very little discussion about contenteditable and editors, so every high quality feedback is really valuable. Editor is usually the last component of a CMS or other kind of system, installed in a hurry, without any understanding of the problem. That, combined with a complexity of the topic and insufficient documentation, leads to frustration. There's no easy solution for this situation and I think that it may only be improved by evangelising developer (every presentation about contenteditable, like yours Garann, helps!) and improving editors (including architecture which you mentioned) and their documentation. That's a long road though, but we're motivated to take it anyway :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment