WYSIWYG Editors and DIVs: A Love Story

By Deane Barker

Why do WYSIWYG editors suck at invisible, surrounding elements?

I’m evaluating a design right now to quote a content management implementation. One of the elements involves arbitrarily shading an area of the page. The HTML jockey in me says, “Just wrap that section in a DIV…” But the CMS integrator in me knows that the client is going to be doing this in a WYSIWYG editor, and how do you do this?

One of the problems is that it’s a somewhat abstract thing for content editors to understand – they don’t know anything about HTML and tags, so they can’t grasp the idea of some invisible, surrounding…thing, around their other content.

WYSIWYG editors don’t help. Try to find easy functionality for surrounding other content in a div and then – and here’s the kicker – putting a class or an ID on that DIV.

If you end up finding or configuring this, then you have to explain it to the editors. It becomes a training issue, because it’s much tougher to understand than just, “Write some text there…” or “Put an image there…”

So, what ends up happening? Tables, baby. A single-row, single-column, single-cell table with a class on it. WYSIWYG editors have all sorts of functionality for tables, and they show them visually very well in a way content editors understand.

A little sad, though.

Rant over.

This is item #151 in a sequence of 354 items.

You can use your left/right arrow keys to navigate