CSS hacking for WYSIWYG CMSs

Chris Heilmann notes that many WYSIWYG CMSs that use in-page editing have problems with CSS based layouts in WYSIWYG CMS - The other user agent. He suggests setting up a repository of which CSS layouts break in what CMS to make it easier for developers to create editor stylesheets that will work around the problems.

It’s certainly a good idea if you’re working with a CMS that has an in-page WYSIWYG editing mode. Personally I would prefer disabling that feature (if possible) since I think it makes the content author focus more on layout than on content. But that isn’t always doable, so making the best of the situation is a reasonable compromise.

Posted on September 26, 2005 in CSS, Content Management, Quicklinks


  1. It’s a valid point that you’ve raised about content authors getting caught up on design - we have a similar problem with clients who use Macromedia Contribute…

    It’s now our policy to allow them to use a limited number of defined styles now instead of allowing them complete freedom. This appears to work well for everyone involved since designs no longer end up looking messy and content appears better presented!

  2. The simple, and best, solution is to not attempt the use of a WYSIWYG editor for the purpose of editing a semantic markup language. Any CMS that offers WYSIWYG editing is broken by design, and should not (at least, such features should not) be used.

    Users that are just editing content should be given plain text boxes and allowed to use a limited subset of HTML (mostly inline elements), (or maybe Markdown, textile, or similar), much like that provided in many blog comment forms.

    They most certainly shouldn’t be editing in anything that allows that to specify presentational details, or even attempts to look anything like the final output. I agree, doing so makes the user focus too much on the layout, and they may make editing decisions based on the way the content looks, rather than its semantics.

  3. Lachlan, how many real editors have you met in your life?

    As explained in the post, the perfect solution would be what you described. However, in reality the technical ability of the common editor will not exceed Word level and they are busy enough getting the content in without wanting to know or care about semantics. I am not saying this is a good thing, I am just saying this is how it is.

  4. Any CMS that offers WYSIWYG editing is broken by design

    I think you’re mixing up interface aspects with the actual functionality. There’s nothing wrong with offering a wysiwyg interface as long as content editors focus on content and not on presentation level aspects. There are some editors out there that do this, most notably XStandard, Xopus and BXE. XStandard for instance applies the ruling stylesheet to the content in the editor offering immediate visual feedback to content editors (in essence saying “all is well”). Dropdown lists offer additional “presentational” sugar but in the form of structural markup (think <strong> looking like classic <b>). This way the editor thinks he/she’s manipulating the presentation while the effect is a syntactic manipulation (semantic is to much honour, that would require real understanding on the part of the editor).

    My point: with the right tooling a wysiwyg editor can be your friend and the editors friend as well making it much more powerfull than a purist tool.

  5. Chris, from my experience, a WYSIWYG editor in the hands of someone that doesn’t have a clue about semantics is a recipe for disaster. Authors should only be interested in content and semantics. But instead, a typical author is interested in how their content will look; and that’s a situation that is not helped at all by the use of WYSIWYG editors.

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.