Why WYSIWYG Editors Suck

Tags: WYSIWYG, jQuery, TinyMCE, CKEditor, Markdown, BBCode, Formatting, Technology

Recently I was given the opportunity to research and implement a way to accept formatted user input that would then be displayed on a website after going through a moderation tool. In this case, the WYSIWYG was deemed the best tool for the job, as it allowed non-technical people to be able to format their input in a web-friendly way... in theory.

After much research, I was able to narrow down the best, most polished and commonly used WYSIWYG editors: TinyMCE and CKEditor. What I failed to realize at the time is that "the best WYSIWYG editor" is like saying "the best politician", in that it is the "least worse" of a flawed solution.

Here's what's wrong with WYSIWYG solutions: They're build on a flawed approach to solving the problem. Most WYSIWYG editors are built using javascript. Javascript is a scripting language that is interpreted by web browsers to provide additional client-side functionality. The problem comes in when javascript is intepreted differently between browsers and operating systems. This causes inconsistencies with how a specific javascript driven behavior will perform in these different scenarios. Other WYSIWYG editors use client-side frameworks, such as Java, Flash and Silverlight. The problem with those is that the client needs an additional downloaded plugin in order to use the tool, and they STILL don't work consistenly across operating systems.

When using a WYSIWYG editor to perfect the formatting on your super-detailed blog entry, you'll find yourself running into a lot of little quirks. Most of them you just work around, but others can stop you dead in your tracks, forcing you to open the HTML and start hacking away on your own. This behavior is found in every WYSIWYG editor available, some more than others.

The "best" WYSIWYG editors actually take in to account every browser and every version, supporting the popular ones, each with their own javascript interpretation and quirks. The problem with this is that the supporting javascript files become bloated. TinyMCE at it's core can be up to 300k which is 3x the recommended page size for an entire web page. I haven't found a single WYSIWYG editor that bothers to load distinct files based on the browser type to improve load time of the tool itself.

The honest truth (redundant, I know), is that as long as browsers interpret javascript and client side behavior differently, there will never be a clean solution for allowing users to format their own submissions without educating them to use a specific syntax of some sort. Which brings me to my next point.

Because WYSIWYG inconsistencies are a known issue, other solutions are often used to allow users to format their input. These are different forms of markup syntax. The most popular being BBCode and Markdown. They don't come without their own set of issues as well, including but not limited to HTML cleaning/parsing issues to prevent XSS (Cross Site Scripting) attacks and educating your users on how to write using the appropriate markup script.

I apologize, but this is another rant where I give no solution. The only solution is for browsers to be 100% consistent in their javascript interpretation, and that's just not going to happen without a mediator framework such as jQuery. Even jQuery has severe limitations when it comes to the specific needs of a WYSIWYG editor.

So when someone in your office says, "Just throw a WYSIWYG editor in there." They need to be aware of what they are proposing. My advice: Pick the solution that's right for your users. Even better, ask your users first.

Add a Comment