WYSIWYG Editors and DIVs: A Love Story

By Deane Barker on October 12, 2009

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 involved 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.



  1. I just had this conversation with a client recently. I’m implementing visual design from another team member and it has some styling for tables to show tabular data. But I had to argue to leave the default table styles alone and provide a class for the styled tables. With a WYSIWYG editor, tables are often used for layout, so the version with no class has to stay invisible.

  2. The legacy eWebEditPro+XML custom XML tags uses tables to display borders and contain authored text. (See screenshot at http://dev.ektron.com/kb_article.aspx?id=595).

    The newer generation of XML, Smart Forms, uses an approach more like HTML forms to capture content. But the author has less flexibility in formatting.

    Visualizing invisible markup, especially abstract concepts unfamiliar to non-technical authors, is a challenge. It’s a conflict between unstructured and structured content along one axis and along the other axis is the conflict over formatting with the content producer wish to tightly control the appearance and the reader who wishes to resize text and browser window for their convenience.

    Eventually, I think authors will need to learn some of the basic structures. When electronic word processors became available, typists had to unlearn to press Enter at the end of each line and allow it to wrap automatically. But, most MS Word users still create an empty paragraph to double space between paragraphs rather than adjust the paragraph style. It’s a matter of doing what’s easy. Perhaps Word will soon recognize the empty paragraph and automatically change the style as it currently does when converting “1.” to an enumerated list.

  3. The biggest hurdle here, I think, is in training. Explaining classes and IDs to nondeveloper minded users usually requires a good, hands-on session with the client. Creating sidebar spots, pull-out quotations, elements of tasteful design … that do not require classed elements are easy in the infancy of a CMS-based web site, but as they grow, content will become diluted and what was once thought to be rare instead becomes monotonous as the clients keeps adding snazzy widgets.

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.