WYSIWYG editor spec – Tables

Interface example of a JavaScript based editor. 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:

FCKeditor add table dialogue, including many sizing and presentational attributes.

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:

Dreamweavers add a table dialogue.

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:

A manipulated version of the Dreamweaver dialogue, reducing the options.

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

Initial view of a table in an editor, each column is very narrow as it's empty. 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:

The Dreamweaver warning when entering tables mode, saying that although easier, it does not display as a browser will.

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:

A tide table, with headings for high and low, sub headings for time and meters, and horizontal headings for months.

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 same table with the headings revealed in each cell, such as &quot;November, high water, time&quot;

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:

Complex table with a heading outlined in red, and the column underneath outlined in a dashed border.

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:

One contribution to “WYSIWYG editor spec – Tables

  1. When importing data from simple CSV spreadsheets, empty cells should be fairly easy to detect for the file processing code.

    Having more than one table of data in a single spreadsheet does happen “in the wild”. Calthorpe often send me Excel spreadsheets like this. I’m not certain but I don’t think the CSV format can handle more than one table per file, so a real-world editor would need to accomodate more complicated formats.

    A bonus of this is that the more complicated formats would, I assume, contain the structural metadata required to identify individual tables. They might go some way towards identifying table headers, too.

    The file processor could apply some heuristic tests to try and deduce the structure of the table and could be quite successful in many cases. I think things like the tide table example, are always going to be tough to sort out, but this could ease the pain somewhat.

    Providing previews and adjustments at the converting stage would be complicated to implement but should be quite possible.

Comments are closed.