WYSIWYG editor spec – layouts

Having cut down what authors can use, they can just about edit regular text articles. However, I haven’t met many clients who would be happy with just that!

The argument for things like the colour picker are that it allows authors freedom to create pages as they see fit. Perhaps this is true for a personal site, but in a professional organisation, a site should follow a consistent style guide. Adding designed elements should be easy, but only from a pre-defined set.

There are certain things that you can’t add by typing in some text and selecting a drop-down to alter the style, because certain things require the addition of code.

Typical examples include a box-out, quote, two columns, or even all three at once:

Example from nomensa.com of a two column area with a quote on one side and box-out on the other.

The markup for this is fairly straightforward (slightly different from the original, but fine for the example):

<div class="col2">
  <img alt="logo" src="logo.gif">
  <p>Quote text...
   <em>- Project Manager, Some web site.</em>
<div class="col2">
 <div class="box">
  <img class="centered" alt="Screenshot" src="screenshot.png">
  <a href="#">Visit the site</a>
<div class="cl">&nbsp;</div>

Two column divss, a blockquote, paragraphs, a div with a class of ‘box’, and a clearing div. But how does a WYSIWYG editor produce this kind of markup?

The blockquote is fairly easy, the user selects ‘blockquote’ from a drop down (the one with paragraphs, headings etc) and it wraps the current paragraph in a quote (see structural code).

However, some designs may need a wrapping div around the columns, and creating nestings would get very messy in current WYSIWYG editors, especially browser based ones. What is needed is a mechanism for adding pre-set bits of code that are inserted into the editor, and treated as a uneditable layout areas.

Interface to add layouts

The type of interface needed to add these layout chunks is not a drop-down, as it is inserting something, not changing it. What is needed is a set of buttons, but without taking too much room in the toolbars. I would suggest using a button that when selected, creates an expandable little box of buttons to choose from:

Example from TinyMCE, with new layout button added, and showing an open box-out with more layout icons within it.

Excuse my poor graphics skills, but I hope you get the idea. This selection of within-page layouts adds in boxes that the editor can fill in the content for, but cannot change the layout without replacing it. (e.g. they can’t drag the sides to affect the size.) They should effectively be hard coded.

Appearance in the editing area

These would then appear in the interface with extra borders, and some way of removing it:

Simple example of a two column layout, dark lines indicate the layout and there is a short filler text for each column.

The user can then edit the filler-text (“Paragraph text”) with whatever they want. In this case they could use any standard element, these are just containers.

A more complex version could tackle the first example I used above:

Example of a complex layout example, including place-holder images and quote.

Ideally the editor could restrict which elements were allowed in each section, but at the least the layout areas should be uneditable.

The type of custom features I had in mind for this type of function are within content layouts. They shouldn’t be needed for adding styles to one element (e.g. a quote), as that would be accomplished by styling that element.


To create the complex example the site developer would need to incorporate their own template-snippets for use. Hopefully the editor would come with several pre-loaded example that the developer can use, extend, or remove.

How the editor does this is entirely up to it’s usual configuration, although I prefer using XML/XSL files for this purpose.

Technorati Tags:

5 contributions to “WYSIWYG editor spec – layouts

  1. This is probably the closest one can get to a WYSIWYG that can be made available to occasional/accidental content managers – ie people within an organisation that have been tasked with publishing copy to a website (and who tend not to care and resent the role).

    But I still feel strongly that it’s better to separate style from the content manager via a form based CMS.

  2. Hi Lawrence,

    One of my assumed requirements (because clients tend to require it) is that they can apply styles, images, tables etc.

    How do you fulfil that for non-technical users with a forms based editor?

  3. Perhaps by making available a wider range of templates for the same content type of page?

    And if there isn’t a template available then go through the process of creating a new one, which is a useful exercise anyway.

    I think of tables, images, flash animations and content items as ‘objects’ to embed in a page and not ones that should be built in a page. Ideally they would be kept as separate entities in the CMS (added using specific tools and properly categorized / meta tagged) and included on a page when required.

  4. I can see that for complex objects (although tables is pushing it), but what about headings, lists, and inline styles such as bold and links?

    I don’t see those as easy things to add in a forms based situation.

  5. I would let text styles / formatting off the hook 😉

    Have you come across any web 2.0 type widgets used in with WYSIWYG interfaces, to allow the building and inclusion of more complex objects?

Comments are closed.