How to handle WYSIWYGs: best practices when developing for regular users

Post date 2010-11-22
Category Digital

I have a love/hate relationship with WYSIWYG editors. Before I taught my users how to work with the editor they easily accounted for 30% of the support tickets at Good Old. Users expect the ability to format their text. Not unreasonable at all. How do we give them that ability? By giving them some buttons to click.

It seems so easy, but somewhere the world implodes and you drown in a floodwave of support tasks. But fear not, padawan! You can prevent a lot of the questions and errors by teaching your users and coding your site well.

One: working with WYSIWYGs, not against

Here's the thing: WYSIWYGs - especially the better ones like TinyMCE - are actually pretty good at generating markup if you follow this procedure:

  1. Write a text document
  2. Highlight the headers and add header formatting
  3. Highlight the bullet list items and add bullet list formatting
  4. And so on

But, as you'll find out when you hand a site over to your users, this is not the way they will do it. They will copy/paste from Word (the world implosion thing), center, bold and change color of images (!), add tables to get the layout they want, and more. Obviously, this isn't good. It's your job to teach the users what to do instead.

Stressing these points usually helps prevent about 80% (very estimated number) of user generated errors:

Two: making sure your site handles WYSIWYG output

A huge bunch of WYSIWYG problems usually comes from poor implementation. If you follow these steps you'll minimize headaches:

  1. Limit the number of editor options. It's great for usability and limits the tags you'll have to think about.
  2. Make sure all of the WYSIWYG tags are styled correctly.
  3. If possible, give the back end editor the same styling as the front end output.

Number one is pretty self-explanatory. Drupal, being the hyper-modular framework it is, usually has a settings page where you can choose what buttons your user can see. WordPress has a pretty limited version of TinyMCE that most users have become accustomed with.

It's at number two we get to do some thinking. How do you style for WYSIWYGs? Say you got the following structure:

<ul class="posts">
  <li class="post">
    <h2>This is a title</h2>
    <p>This is a paragraph from
       a WYSIWYG.</p>
  </li>
  <li class="post">
    <h2>This is another title</h2>
    <p>This is another paragraph
       from a WYSIWYG.</p>
    <p>This is yet another paragraph
       from the WSYIWYG.</p>
  </li>
</ul>

You'll have to style the <h2> and <p> somehow. It's not uncommon to do this:

.post h2 {
  font-size: 2em;
}
.post p {
  margin-bottom: 1em;
}

But what happens when you have to apply WYSIWYG styling to, say, your widget areas? With luck it'll look like this:

.widget h2,
.post h2 {
  font-size: 2em;
}
.widget p,
.post p {
  margin-bottom: 1em;
}

...and if we're really sloppy we'll duplicate the styles entirely, resulting in hard-to-maintain stylesheets and incoherent looks. But hey, what happens when we do this?

<ul class="posts">
  <li class="post wysiwyg">
    <h2>This is a title</h2>
    <p>This is a paragraph from
       a WYSIWYG.</p>
  </li>
  <li class="post wysiwyg">
    <h2>This is another title</h2>
    <p>This is another paragraph
       from a WYSIWYG.</p>
    <p>This is yet another paragraph
       from the WSYIWYG.</p>
  </li>
</ul>

.wysiwyg h2 {
  font-size: 2em;
}
.wysiwyg p {
  margin-bottom: 1em;
}

This way we can define which areas are output by WYSIWYGs by adding a .wysiwyg class to the parent element. Presto! A minimum of redundant styles. We can even extract the styles to a separate stylesheet to help with number three in the list above: make sure the editor uses the same style as the front end. (You use a filter in WordPress while the Drupal WYSIWYG module has a setting in the interface.)

But Linus, I hear you say, how do I know how the elements should be styled? I can't take every situation into account! No, but you can use your typographic knowledge to make reasonable guesses! If you want a starting point you can use my continually evolving WYSIWYG stylesheet and modify it for your site. As a bonus, here's a test-text you can use to test them. They cover WordPress (3.0.1) styles well, and should be a good starting point elsewhere.

There. Now you've got no excuse for sloppy WYSIWYG work. Go kick ass!