WYSIWYG editor spec – Tables

Each of the editors I’ve been looking at allows the addition of tables, but none of them allow the easy insertion & manipulation of a data table, i.e. one with headings. I deal with data tables quite a lot for windsurfing results, and the only program I’ve found for decent table editing is Dreamweaver. (Please leave a comment if you know of something else!)

Allowed & required functions

The first assumption is that tables are for data, not for layout, so any table added should for tabular data, which by definition should have headings. Therefore the creation and editing of a table should allow manipulation of table headings. A simple data table should be the default.

Secondly, as a CSS friendly editor that separates content and style, there shouldn’t be any presentational attributes. Things like cellpadding and cellspacing aren’t needed any longer, unless you need an identical appearance in Mac IE and Netscape 4. So apart from standard attributes, summary is the only other attribute for the table element in the allowed HTML.

Styling tables

In order to have minimal presentational aspects in the interface, you need some pre-set styles. There are two main aspects the user should have control over for most tables, the headings, and the general style of the table, everything else should be data.

The style of the table (likely to be a drop-down of options from the defined CSS files), should provide styles defined around the site’s design. These styles would affect the borders, colouring and fonts.

There also needs to be a mechanism to choose whether the headings go across the top, left or both. (Complex tables are covered below.)

Getting structure and appearance to match

An important aspect of getting non-technical people to use the structure properly is to ensure that how the table looks is right when the structure is right. I’ve seen people creating apparent headings with bold, rather than using headings, even when headings were available and easy to add. There are two main ways to combat this:

1. Use a style definition such as table strong {font-weight: normal;}, or prevent bold/strong being applied in tables by the editor.
2. Ensuring that the styles are defined for headings as requested by the users, and/or by the style guide (if there is one).

Adding a table

The usual ‘add a table’ button gives a good indication of what code will be added, this (bad) example is from FCKeditor is typical:

The default output for the table tag is:

<table width="200" cellspacing="1" cellpadding="1" border="1" align="" summary="">

Not ideal, and missing any means of applying table headings. Dreamweaver has a different approach, and includes a method of adding structural headings:

Still, there are several things here we don’t want, such as the cell attributes, and there shouldn’t be a no-heading option. With a little image-manipulation, this would be my ideal for adding a table:

I have included width, but only for percentage widths. It can be useful to make a table 100% wide, or sometimes a smaller percentage of the width of the container, but working with liquid layouts and variable fonts sizes means that pixel sizing should not be available.

One last thing an editor could (or should?) add for simple tables would be odd-row hooks for styling. I.e. for each even row add a class: <tr class="even">

Although you can plug this problem using JavaScript, this is a small addition of HTML that provides an easy hook for CSS, and is easiest done through a programmatic mechanism such as an editor. Then applying styles to create stripped tables is easy.

Editing tables

One of the usability issues with adding an empty table is that it appears very narrow without content, this example has a caption of “testing”. This is fiddlly, and encourages editors to drag the table or column widths, which in current editors sets the width in pixels.

Tables should not have draggable columns, as there is no real way of converting this to percentages. In a complex table, cols could be used to apply different widths to different columns.

Optionally, Dreamweaver’s “table mode” is a good way of getting around this, although it does make it appear quite different from the final version, as the warning dialogue suggests:

Once a table is in place, there are certain functions that are best accomplished with a context menu (often a right-click). Functions like adding or removing columns or rows need a context menu because the cursor location in the table can be used to identify where the new cells should be added.

Importing data

In practice, it is rare to be creating a table before you have the data. It isn’t easy to type into each cell, so being able to import data is vital for ease of use. However, I would consider this advanced functionality, the above would be a minimum an editor should provide.

There are two main plausible methods: import from a (CSV) file, and cut ‘n paste.

Import from file

The typical scenario would be for a user to have a spreadsheet or similar file that is the source for the table that they want to add. The steps would be:

Select ‘add table’

Using the usual add table button, the file aspect would be another button or tab in the table dialogue.

Select the data

The first aspect is to select the file with the data intended for the table, but there are two potential mechanisms for how much of that file to use:

• Inform the user that they need to save a ‘concise’ version that removes any space above and to the left of the data.
• Preview the data, and allow the user to select the area of the spreadsheet to use.

Obviously the second method is much more difficult to implement (I’ve not seen it done), but would be very helpful.

Apply headings

Using a similar mechanism to the Dreamweaver dialogue above, the user would add the headings and style of the table, preferably with a preview.

Insert table

The table gets added to the content, and after this point is considered part of the content.

I use a macro in my text editor to convert from CSV to an HTML table, it is creating the interface that is the challenging aspect.

Import from cut and paste

Another typical scenario would be for a user to have a source file, and want to copy part or all of it into a table. In this case the user would create a table with the usual interface, select and copy from the external file, and paste into the table.

The requirements for this are simply that the editor supports (kruft-free) pasting into a table, and that it matches the columns and rows or rejects the paste. It is also necessary to allow users to select multiple cells with the keyboard.

Complex tables

I define a complex table as any data table with more than a row or column of headings. Complex tables are a desirable but not required feature, mainly because they are hideously complex to produce properly. Not even Dreamweaver supplies a WYSIWYG editor for complex tables, and it makes no effort to produce the required attributes (at least in the MX version).

Although Joe Clark created a table with just about everything in it, I tend to use a real life client example (and one close to a windsurfer’s heart) of a tide table:

Using Gez Lemon’s excellent table inspector, you can see how the headings have been applied, and I’ve also checked the readout in Jaws, which worked fine:

The type of code this relies on including several elements and attributes, from <colgroups> for the upper headings, to axis for the horizontal headings and (most annoying to edit) the headers attribute on every cell. (See the WebAim tutorial for more.)

That example is produced from a database through an automated template, no-one would want to edit that by hand, so automation of some kind is vital for complex tables. But is it too complicated to do?

One way would be to create a new table from a pre-set selection like the main Dreamweaver interface, which would be a good start, but it could not cover the variety of different tables you might have. It also doesn’t cover the import scenario where you have data already.

Ideally, you would be able to either start with a new simple table, or import data as described above. Then, you would go into a “set headings mode“, and define the relationships.

Defining headings

For example, you would fill in the cells (i.e. put the text in each cell), and then bring up a context menu, set the heading or sub-heading, and select the column/row/cells that it applies to. Forgive my poor graphics skills, but this might be how you would see the tide table example when defining a heading:

I would suggest this is a distinct mode, as it is a phase (or even wizard) that you go through to start with, and probably don’t touch again. There are other functions that would be part of the normal context menu for tables (add/remove columns for example), so one of those options would be “adjust headings”.

This WYSIWYG editing would automatically add IDs for each heading, and defined options of which cells they can apply to. I’m not entirely certain if you could automatically add <col>s and <colgroups>, but it would be worth trying.

Some of these interface methods are new to this domain, are there better ways to deal with complex tables in editors?

---

Technorati Tags:

• accessibility
• editors
• WYSIWYG
• tables
• HTML tables