Forget WYSIWYG editors - use WYSIWYM instead

A huge problem with almost every CMS in existence is the extremely poor quality of the code produced by their WYSIWYG editors. There are very few WYSIWYG editors that come anywhere close to creating fully semantic and accessible markup, as noted by Peter Krantz in Evaluation of WYSIWYG-editors.

Since visual gadgetry like WYSIWYG editors sells, every CMS has to have one. Most are based on Internet Explorer’s MSHTML editor, which creates absolutely horrific markup. That, in turn, makes it necessary for Web professionals who want to reduce the risk of clients unknowingly ruining the website’s semantics and accessibility to disable features and implement more or less advanced code cleaning procedures. It is a mess.

Despite any cleaning or filtering you do, there’s the inevitable use of the few features that are still there to create presentational effects. Using data tables to create nice-looking headings, using level 6 headings instead of strong emphasis, and using emphasis to make entire paragraphs italic are just a few real world examples. WYSIWYG editors simply do not work, especially when handed over to untrained people.

Because of the problems caused by WYSIWYG editors I have toyed with the idea of providing a much simpler interface for content editors. Markdown, BBCode, and Textile are a few possible solutions that ensure valid markup and increase the likelihood of it being semantic. The problem would be making clients accept working that way, directly editing pseudo markup. Most clients wouldn’t, so that option is ruled out.

But there is another kind of editor that is better suited than WYSIWYG for content-driven, client-edited sites - the WYSIWYM (What You See Is What You Mean) editor. In Visually Editing Semantics - What You See Is What You Mean, Peter Krantz mentions one such editor: WYMeditor.

From the WYMeditor site:

Our goal is to create a XHTML strict web-based editor which will be usable on many platforms, whith the help of the Open Source Community.

Sounds great! WYMeditor is developed to let editors focus on the meaning of the content they are editing, and thus doesn’t offer any way of changing colours, borders or fonts. Neither does it have a gazillion other sales brochure features. It does just the basics, which is good enough 99 % of the time. The markup it generates is Strict XHTML (if you want HTML instead all you need to do is convert the markup).

A WYSIWYM editor won’t solve the problem of people using their tools the wrong way, but I believe it will give people a better understanding of semantics.

There are a few limitations, of course. This is an early version, after all. Besides the issues Peter notes in his post about WYMeditor, here are a few more things I noticed:

  • Table accessibility. There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables.
  • Table resizing. It is possible to size tables by dragging handles. Doing so is reflected in the markup. That needs to be filtered out at some stage before saving the page to the database.
  • Incorrect nesting of lists. When you create nested lists, the current list element is closed before the next level ul or ol is inserted.

Aside from those issues, which are very minor compared to the nightmarish markup most WYSIWYG editors spew out, WYMeditor is looking great. I really hope this editor catches on.

Posted on December 12, 2006 in Accessibility, Content Management


  1. I would add to the above: incorrect usage of strong and em. If a user clicks a button labeled “b” or “i”, it is foolish to assume that they meant “strong emphasis” or “emphasis”. If a user clicks “b”, it should use the b element, not the strong element.

  2. In a cursory look at WYMeditor, it’s still based off the MSHTML (IE) and Midas (Mozilla) engines. All they’ve done is implemented a filtering system to attempt to clean up the mess.

    I’ve often wanted to attempt an editor of my own but avoid MSHTML and Midas altogether (I built a rather extensive editor about 5 years ago that used the DEC/MSHTML). I had heard someone else had tried this approach (Jot? Dojo?) but I never got around to checking it out.

    @Jeff: the problem is that editors are targeted to non-technical staff who are used to Word. Therefore, B and I (and as the original article interestingly took into account, the use of BLOCKQUOTE for indenting) are familiar. Branching too far from that risks making the editor simply too confusing to use.

  3. Ever tried Moxiecodes TinyMCE?

  4. @Jonathan: I don’t disagree. The editor should stick to the b and i buttons. It should just use the b and i elements, too.

  5. December 12, 2006 by David F

    Jeff is correct though in that you should not make the assumption that b and i should be strong and emphasis. To a screen reader this would be highly annoying and they would rather not be yelled at by their screen readers.

  6. The biggest problem with these rich text editors is the fact that a lot people use M$ Word to type up their text. Which results in a barrage of hideous markup when copy + pasted into the editor.

  7. Did you look into Xopus? It’s a XML editor (including validation!), right now it only works in IE [1]. It’s used by a number of large companies – don’t have the details but it includes Philips for instance.

    (Disclaimer: I work part-time for Q42, the company behind Xopus.)

    [1]: Before everybody starts asking for Firefox, Safari and Opera support: turns out that’s actually very difficult.

  8. Aren’t “b” and “i” deprecated in XHTML? So they should be using “strong” and “em”? Right? If this is to be a true XHTML editor?

    Correct me if I am wrong. Otherwise, sounds like a great idea to me.

  9. XStandard is by far the best I’ve seen. XHTML Strict compliant, cross-platform, uses CSS for everything, and is entirely extensible: you can add your own CSS declarations directly to the interface.

  10. It looks very promising. I think if I were deploying a CMS right now, I’d use XStandard but this could be the ticket going down the road.

  11. “i” is deprecated but “b” is still valid. I much prefer it for its brevity.

  12. Oops. I wish I could edit my previous post. Neither B nor I are deprecated. Note to self, look before you leap. :o(

  13. December 12, 2006 by Justin Makeig

    I’ve had much success with Xopus as well. The main benefit of Xopus and its XML-based ilk is that you get all the power of XML Schemas to define a true domain-specific vocabulary, for example a recipe document for a health and fitness site. (A recipe has a set of ingredients and list of preparation steps. Each step optionally references one or more ingredients, etc.) Xopus gives you a friendly way to create and edit instances of these schemas that would be familiar to anyone who has used a modern word processor. This results in much more semantics than an XHTML document in most situations. These documents can then be transformed with XSLT into XHTML or whatever else you might need.

  14. Another great (free) product is Fckeditor ( I´m trying a minmized version out right now with great result. I think an editor can never produce 100% valid, correct and semantic code. An editor should only be able to add headings, tables, images and other semantic elements. If the user should be able to add “design” they should be controlled by css and classes, Fckeditor can do this. I also think that educating editors to think about semantics is the best way to go, of course the editor should help them do the “right thing”. An other thing to think about is that most people work with Word and then paste the document into the editor. It´s really important that editors can cope with this.

  15. I have to say I’m not convinced that this type of editor will ‘fly’ with clients. It is unusual for non-technical people, or even technical non-web people to understand the separation of structure from style. To get the best out of that type of interaction style you implicitly need to understand that what you are adding will transform when displayed on the site.

    That isn’t to say there is a better option yet, or even a good one.

    I’ve been trying to define what I’d like out of a WYSIWYG editor for a little while, I’m almost there. Next step will be incorporating the authoring tool accessibility guidelines and then trying to get one or more of the editor developers to listen.

    Whilst doing that series I’ve been trying some editors to see what they can do (TinyMCE, FCKeditor & Xstandard), and Xstandard has certainly produced the best code. It seems the JavaScript based editors have a real mountain to climb in terms of cleaning browser produced markup.

    Unfortunately none of them are keyboard accessible (yet, Xstandard is working on that).

  16. I was thinking, is there a good flash-based WYSIWYG editor? Flash works cross-platform in 95% of browsers, and it works exactly the same in each and every one. It just seems to be the ideal medium for such a product… anyone know of one that works well?

  17. Thanks for the heads-up, this looks like something to keep an eye on. Clients breaking stuff by using editors in a way I’d never contemplated happens more often than I’d like. This looks like a good solution for the client, and a headache saver for me.

  18. Hi,

    Thanks to Roger Johansson and Peter Krantz for their great articles!

    Some points need to be clarified:

    WYMeditor is written in Javascript, so it doesn’t require any installation (for instance, XStandard is a plugin).

    MSIE contentEditable and Gecko Midas generate ‘tag soup’, so WYMeditor cleans up the code - but it isn’t perfect (yet). If you need 100% strict compliance, you can use HTML Tidy at the server-side.

    WYMeditor is focused on the end-user, so we use B for strong and I for emphasis - but the icons are easily customizable.

    @AlastairC: our customers (non-technical people) use WYMeditor, and don’t have any problem with it. A one-hour training is sufficient!

    @huphtur and Jens: While pasting from Word, WYMeditor takes the raw text and inserts clean paragraphs. If it doesn’t work in your browser, please feel free to post a comment in the forum (

    About tables, or other elements: the key point is to customize the ‘Classes’ menu, and/or use the custom templates, so it’s easy to generate the code you need. But maybe we’ll add table accessibility by default in the future.

    Another key point: WYMeditor is open source!

    BTW, your feedback is greatly appreciated!

  19. To second what Alistair said, I think a lot of this problem is human rather than technical. I’ve trained users in a somewhat simplified HTML interface, talking to them about HTML being for meaning, visual stuff being handled elsewhere, and seen them nod and understand and say “Yeah, that sounds like the best way to do things”. The first thing they did once they got their hands on the CMS was put a bunch of images on the site, to jazz it up a bit. Then a load of emphasis everywhere.

    In my very limited experience, most people don’t give much of a hoot about creating meaningful data (how many people do you know who bother filling in track information in iTunes?), and don’t want to distinguish between changing the look of their web site, and editing the content. I don’t believe there’s any technical solution to this. It’s a people thing, as as the benefits of meaningful data are (I think) mostly intangible and not immediate, it’s always going to be tough to encourage people to create it.

  20. To second what Alistair said…most people…don’t want to distinguish between changing the look of their web site, and editing the content. — pauldwaite

    Why should they? It all comes out looking the same to them. The only reason we care is we have to see the internals, and it’s annoying when they’re a mess. Out of sight, out of mind. You just have to convince them that if they want to do it the messy way, it’s going to cost them more money in the long run.

  21. I think the problem is technical to some extent. The way content is styled should always be up to the site designer, not the guy who writes and inputs copy. Thus, an ideal website editor lets someone type and produce structural markup only, and limits formatting only to those style classes developed by the designer.

    WYMeditor seems like a terrific start. I’ve dreamt of something like this and toyed with the idea of trying to create my own Javascript-driven editor without using MSHTML or Midas.

    If only WYMeditor worked in Safari.

  22. December 13, 2006 by David Hall

    On the whole b vs. strong issue, anything wrong with a simple ?

  23. December 13, 2006 by Daniel

    Why would you like to save your data in HTML format?

  24. That editor looks pretty awesome. I hate the one we’re currently using so much that I’ve even thought at trying to build one myself with basic features; most on the market are so heavily overfeatured

  25. Can I just call upon my Power Of Pedantry to suggest that this should surely be a What You Mean Is What You Get (WYMIWYG) instead?

  26. The way content is styled should always be up to the site designer, not the guy who writes and inputs copy. Thus, an ideal website editor lets someone type and produce structural markup only, and limits formatting only to those style classes developed by the designer.

    I think you’re right. I really don’t want my clients to add new colours, typefaces etc, even if they’re using valid markup. So far, I’m pretty happy with TinyMCE - you can configure it to remove every button that generates bad markup, and users can choose classes defined by the designer. Having said that, WYMeditor is probably even better :-)

  27. Funny, I’ve not had any people complaining about the lack of WYSIWYG editing in my CMS. A simple combination of a content type dropdown and a textarea does keep the output perfectly semantic and predictable.

    I try to let people understand they should manage their content, not the appearance of that content. Once they grasp that, everything else becomes a lot easier.

    Disclaimer: I don’t have too many customers using my CMS yet, and I perhaps never will ;)

  28. By analogy with “B” and “I” buttons - then clicking an icon with an anchor (or chain) on it should write “anchor” or “link” into textarea? Those are visual editors, so “B” and “I” represent visual effect on emphasized/strongly emphasized text not how they are marked up in code.

  29. My point has nothing to do with end users. Nothing about the interface needs to change. The “b” and “i” should stay “b” and “i”, because renaming them to “strong” and “em” would serve only to confuse users. But, and this is an important but, italics and bold are used for more than emphasis! For instance, sometimes the defining instance of a term is rendered as bold. It would be absolutely wrong from a semantic standpoint to mark this up using a strong element. Citations are made using italics; it is inappropriate to use em for them. In fact, HTML defines the cite and dfn elements for just these purposes. Obviously, it would be too confusing to the user to add strong, em, cite, dfn, etc., to the repertoire of your editor. Here is my fundamental point: if a user clicks a button that is labeled “b”, they are not indicating that they want strong emphasis, but are instead indicating that they want their font bold! It is true that they might be doing this to strongly emphasize a portion of text. It is also true that they might be doing this to show a defining instance of a term. Or they may just think it looks better! You can’t know, you can’t infer, therefore the semantically correct thing to do is to insert a b element. Not a strong element. Leave the “b” button. Have it insert a b element. Please. I’m sorry. I realize this is a minor point and a fine distinction. It looks like the rest of the editor is pretty darn cool and it has a lot of promise. WYSIWYM is definitely the way to go. I loved it in LyX, and I think this could be just as cool. But my point still stands.

  30. Based off the goal, I believe TinyMCE to be a better solution once a person wraps there head around how to configure it for (x)html strict. Plus, its got great documentation and a large list of supported OS’s/browsers.

  31. I’m a lead developer of SPAW Editor. When we released first version of our editor we were trying to concentrate on it being visual content editor rather than HTML editor: font controls were not included in default toolbar items, the only CSS classes available were those defined by the admin, etc. We still stand behind this but user feedback tells something different. Users want web WYSIWYGs to be as close to Word (or at least to Frontpage/Dreamweaver) as possible. You can try and educate them about how bad and non of their business is to mess with site’s look and layout but most of them still want to have as much control as they can. Users even want WYSIWYGs to include controls that will let them insert web forms and even PHP code. You sure can limit use of these things as a CMS developer but you cut a large piece of potential users by not implementig such options in a WYSIWYG. After all a huge percentage of WYSIWYG users are site owners writing content for their own sites and they want to have all the tools even if they never use them

  32. I did a review of WYSIWYG editors back in February. Most editors have the ability to customise so that you don’t give users too much power, in effect the ability to make them a WYSIWYM.

    On another point on how people actually work, I’ve observed hundreds of people up and down this little country cut and paste from MS Word into the WYSIWYG of their CMS. Stripping all the gunk from Word while keeping the “meaning” or semantics is something I’ve yet to see done really well.

  33. For a recent knowledge base that I created for work, I decided to forgo an editor altogether in favor of text parsing a la Textile and trying to infer the markup of the text based upon relatively simple formatting markup, line breaks, etc.

    Unless people really need specific markup or advance formatting, I find that it’s easier not to give them too many choices. Too often people want to add in a bunch of colors or styles that clash with the overall design of the site - and the copying from Word is definitely as issue.

    When I have had to use an editor, I’ve found that the FCK editor works pretty well and is able to be extended relatively easily.

  34. This WYMeditor doesn’t load at all in IE6 for me. Try this instead It’s much better (considering it actually works for me), and it does use strong and em for all you ultra-purists.

  35. December 14, 2006 by Jim Stone


    “Users want web WYSIWYGs to be as close to Word (or at least to Frontpage/Dreamweaver) as possible.”

    Ain’t that the truth! I’ve implemented editors where I’ve only given clients the ability to format using CSS classes. They come back and tell me they want “fonts and colors like Word” - and that’s a quote.

  36. @jun

    This WYMeditor doesn’t load at all in IE6 for me.

    This is strange - WYMeditor has been tested with IE5.5 to IE7, even with Linux + Wine + IE6.

    Could you please post this bug in the forum?

    Thanks in advance for your help.

  37. if you paste directly into the window from MS Word (in FF), you still get a big mess in WYM Editor

    <p class="MsoNormal" style=""> </p>
    <p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 14pt;">

    … and if I click the “paste from word button” with an entirely empty main textarea, nothing pastes at all.

    This is a GREAT idea… if you can really stop the evils of MS Word.

  38. Does anyone know what OpenOffice uses to generate XHTML? It seems like a good platform to build on, it generates somewhat semantic code and puts styling as CSS in the head tag.

  39. Man I’ve been drooling over WYMEditor for a while; it’s a bit sad that this small project is the only WYSIWYM effort out there.

    In response to some of the comments here: While I agree we will probably need to continue to support users’ desire to edit what they see and equate visual with semantic, I think it’s critical that we continue to nudge the “lay” people in the right direction.

    I don’t consider myself an expert in semantic HTML, but I have made it a goal to push, educate and otherwise cajole writers and editors I work with to not only understand semantics but embrace it. Ultimately, it’s the person who writes or edits the content who best understands its semantic meaning rather than developers and designers like ourselves.

    Since these same individuals are in my experience frequently terrified of anything that looks like code (i.e. anything between angle brackets), a simple, well-designed editor that helps and encourages them to convey meaning would be huge.

    So in this sense, our best hope lies with admin/CMS users. As for true end users, I think we’ll have to live with “B” and “I” buttons for a while yet.

  40. @warren

    OK, I’ll check that. Actually I don’t use Word, so this is my fault ;)

    Thanks for your feedback.

  41. Honestly, there really should be no use for a WYSIWYG editor of any kind. It is my opinion that they a) kill the industry and b) they allow people to create sites that are just not worthy of being online.

    If you are serious enough about having an online prescence, learn how to do it correctly without the need of such editors. If you are not serious enough about it, or are not up to it, hire someone who is. That is why we (freelancers) break our necks month to month to produce quality websites. Inferior methods will always breed inferior results, period.

  42. December 16, 2006 by Stevie D

    Honestly, there really should be no use for a WYSIWYG editor of any kind. It is my opinion that they a) kill the industry and b) they allow people to create sites that are just not worthy of being online.

    That’s going too far. Personally I’m happy in the abstract world of raw code, but I know a lot of people who have trouble visualising the results of that. That’s especially true for data tables and nested lists, where you can easily lose yourself in tags.

    I have no problem with people using WYS editors to lay down the content of the page, as long as (i) the editor encourages semantic formatting (eg use of headings) rather than point-and-dribble change the font size and colour, (ii) they know what good code looks like, and go through the source code to tidy it up afterwards.

  43. I can’t believe that Xinha hasn’t even been mentioned here. It works perfectly for my uses.

  44. We decided to go with Xstandard for our internal CMS. As others have stated, it’s by far the best option if clean XHTML is what you require. You can do a lot to both restrict and enable authors into using the specific markup you’d like, plus it has a fairly robust table editor.

    For instance, you can set up a style called ‘this is important’ and have xstandard insert a custom tag such as for you. In a sense, it enables you to make it a ‘wymiwyg’ editor.

    That said, we still encounter the same problems…people using HEADERS to make text big. People complaining that they can’t make their text purple with a dashed border and yellow polka-dotted background.

    I really like the concept and implementation of WYMeditor. There is certainly a place for it.

  45. I’d like to point out Loki, which is an open source WYSIWY[G|M] XHTML editor that attempts to guide users toward the use of semantic elements.

    For example, when you insert a table, you get headers automatically. You can’t create a table that has fewer than 2 rows and 2 columns. Blockquotes are clearly labeled as such, and hitting the “indent” button has no effect when you are not in a list.

    I’ve been party to the development of this editor, and we’ve been trying to walk the fine line between having it work in a “Word-like” enough fashion that the learning curve is low, but making the non-semantic features either removed or buried where we don’t feel like we can remove them entirely.

  46. December 22, 2006 by Martin G.

    I think WYMeditor is too clunky and akward to use. It took me long time to figure it out.

    I use XStandard Lite. The editor has no bad features like color selector and font selector. So the user cannot use formatting instead of meaningful markup.

    Plus a good editor is more then software itself. I select XStandard in part because of very good technical support.

  47. 6 is right - the real problem is not the editors because there are some good ones. Fckeditor is what we use at Terapad and it produces xHTML compliant code that’s nicely formated. It’s also vastly more configurable and powerful than the WYM editors currently available.

    Markdown, BBCode are far to simplistic. IMHO it should be about what users want. Check out myspace - everyone admits those layouts look like dog’s breakfasts but that’s what people want, whether we like it or not :D If you take their blinkies away they’ll just go somewhere else, and rightfully so.

  48. January 25, 2007 by janke

    “Honestly, there really should be no use for a WYSIWYG editor of any kind. It is my opinion that they a) kill the industry and b) they allow people to create sites that are just not worthy of being online”

    Is that true? I know for example that big companies like Philips insist on XML editors, I believe they use Xopus. Has anyone an idea why? I am relatively new in this field, so can anyone explain?

  49. April 18, 2007 by Jason

    The one problem I see with every editor is that anyone who shows up at the page can access it. Perhaps this is fine for blogs and cms. We are bombarded with requests for a WYSIWYG editor that can edit another file. This way, when you are through, and the general public visits the “other” file, there is no WYSIWYG markup or textarea or visible editor to fiddle with. I think many people are looking for a web based “off-line” editor. I have reveiwed more than 30 WYSIWYG editors and they all suffer from this same lack of protection.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.