WYSIWYG editors spec – adding structural code

When an author changes the appearance of a page, those changes should be represented in the underlying structure of the page. This post looks at what the interface should be.

With a WYSIWYG interface, there has to be an area that appears as it will when published, which means to change bits within it, you need one or more toolbars. This is an exploration of what those toolbars should do.

Block elements

You could argue that the author doesn’t need to know anything about block or inline elements, they should simply apply a heading (block) or bold (inline). I would agree, but these elements behave quite differently when published, so on balance, I would rather make that explicit in the interface, and mark the behaviour as different.

The default installations of the editors don’t tend to separate block and inline elements, this is a screen shot from X-Standard lite:

The issues I’ve seen with this are that there is a gap between what the user thinks will happen, and what does. I’d like separate mechanisms for applying block and inline elements, and buttons for elements that require a more wizard like approach (e.g. tables and images).

Essentially, when applying a block element (heading, paragraph etc.) it shouldn’t matter whether some text is selected or not, the change would apply to the block element around the cursor.

There are quite a few block elements (headings etc.), so a drop-down widget seems like a good choice:

That drop-down would default to paragraph, and include:

Paragraph

<p>

Main heading

<h1>

Heading

<h2>

Sub-heading

<h3>

Quote (block)

<blockquote> <p>

There are several other block elements that are not in that list because people are either used to them being separate (lists, horizontal rule) or because they require more information (tables). These need their own buttons:

Bulleted list

<ul><li>

Numbered list

<ol><li>

Definition list

<dl><dt><dd>

Horizontal Rule

<hr>

Table

<table> (would require a wizard approach).

Inline elements

Applying inline elements generally requires the user to select a certain amount of text and then select a button which then wraps the text in the appropriate tag (see below). Some editors allow the user to switch-on bold (for example), write, and then switch it off, and carry on writing. ‘m in two minds about that, it means that buttons to not act consistently, but it is a learned behaviour from other editors. So long as it replicates other editors and doesn’t disrupt the markup, it should be ok.

link

<a>

image

<img>

bold

<strong>

italics

<em>

strikethrough

<del>

code

<code>

quote

<q>

subscript

<sub>

superscript

<sup>

acronym

<acronym>

There are a few others that you could include: cite, dfn, ins, or others from the allowed HTML list, but these are the ones I’ve found are most commonly used.

The exceptions are images, links and acronyms; which require more information, however they are still inline items, and follow the same type of rules.

That leaves a useful set of elements to work with, and a means of applying style variations:

(NB: This example was created with TinyMCE, which is missing acronym and doesn’t necessarily produce the correct markup for each item.)

Interface variations for elements

There are certain behaviours that you would want an editor to show that vary by the element being used.

Paragraphs, line breaks and spaces

By default, an editor should make a new paragraph when the user presses return. A line break can be added with shift-return. This applies to headings as well, so that upon return a new paragraph is added below with focus. If the cursor is not at the end of the element, it would split the current element into two.

An editor should not insert non-breaking spaces ( ) if the user presses space more than once, it should ignore the attempt.

Blockquote & Quote

One of the primary interface problems with blockquotes is that they are often referred to as indentation – a very clear problem when trying to get non-technical people to use them correctly! Blockquotes are also tricky because it allows other block elements within it, usually paragraphs. I would suggest that:

• Blockquote must be referred to as “quote”, “block quote” or similar, not indent.
• When a paragraph is made into a blockquote, there is automatically a paragraph inside and below the blockquote, with the focus remaining in the blockquote. This would enable the user to add paragraphs or other elements within the quote and press down to leave the quote.
• There must be a mechanism to add the cite attribute (a URL). This could be:
  • a ‘properties’ command (button or context menu).
  • A wizard approach where a box pops-up with URL and text fields.
  • Something is added to the interface that the user can select, for example:
    

The quote (q) element is an inline version, so cannot contain block elements but should allow the addition of the cite URL.

Lists

There are two primary behaviours needed for lists:

• Pressing tab within a list creates a correctly nested list.
• When the cursor is within the last item and it is blank, pressing return will remove the item and start a paragraph below the list.

Very few editors do nested lists properly, to many times they will incorrectly do this:

<ul>
 <li>Item one</li>
 <ul> 
  <li>sub-item one</li>
 </ul>
</ul>

However, a nested list should be within a list item.

Links, acronyms & images

Images will be covered in greater detail later, but all these elements require more information than simply applying a style. An image requires an image location and alternative text, links require a URL, an acronym should have a title. Selecting the button should open up a dialogue to take the appropriate information.

Context menu

A context menu (often right-click in windows, or control-click in OSX) can be a very useful short-cut to changing the selected item. These menus should be dynamic (i.e. change depending on the context), and given browser controls I am surprised that editors don’t usually provide a button for this type of function, as right-clicking can be over-ridden by the browser.

In the same way that the style drop-downs should be dynamic, the context menu would provide access to the additional attributes of the element in question, but only those defined in the allowed HTML.

The JavaScript based editors do not produce a context menu for me (they may on Internet Explorer for Windows), surprisingly neither does Xstandard, although that could be because it’s the beta version for OSX.

A context menu would be a useful addition that allows quick access to attributes of each element, as well as the usual cut and paste.

How the editors do

Previously I have been through each editor at this stage, however, it’s a slow process trying the different configurations for each. Instead, I’m going to leave that to the end, and instead build up a check list of all the points covered in each of these WYSIWYG posts. Then I can test each editor from start to finish, not only establishing the best and worst points of each, but finding the best configurations for each.

Coming soon, how editors should let you add alternative text to images and manage images.

---

Technorati Tags:

• accessibility
• editors
• WYSIWYG