Table Design

Tables in web design is very substantial subject. For this article, I am going to keep it very brief and simple.

Thought should go into the design of tables. This is not usually the norm. Many designers feel they have free rein to use tables to layout web pages. Some of the leading WYSIWYG software (such as Macromedia's Dreamweaver and Adobe's GoLive) use tables for absolute positioning of elements on the page. Many times, these elements on the web page will be placed in individual tables and nested inside other tables. This may not be apparent on a typical computer screen, but can cause difficulties for some users.

Web standards express tables are for laying out information in tabular format. Before the introduction of style sheets, tables had been the desired method for page layout that was not linear. This creates a conflict between web standards and accepted usage. A designer may choose one group or another, or may decide to take a workable compromise that complies with both methods.

Who Is Making The Web Standards?

Many believe web standards are made up by the two main browser people Netscape, Microsoft, or even the government. This is not true at all. The two main groups currently involved in HTML standards are the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). W3C puts together specifications for web standards. The most essential web standards are HTML, CSS, and XML. W3C will not continue to develop HTML. Future W3C work will be focusing on XML. The latest web standard is XHTML 1.0.

HTML has gone through several changes over the last few years. XHTML 1.0 was the first major change to HTML since 1997. XHTML is aimed to replace HTML. XHTML is almost identical to HTML 4.01. There are a few simple rules that must be followed in order to comply with the XHTML specifications. XHTML is a stricter and cleaner version of HTML. XHTML is HTML defined as an XML application. XHTML is the predecessor and bridge to XML. Currently, XHTML 1.0 is the standard.

XHTML is less forgiving than its predecessor, HTML. This is because XHTML documents are XML applications. The important differences between HTML and XHTML are:

1. XHTML tag and attribute names must be in lowercase
2. XHTML tag attribute values must be within quotes
3. XHTML elements must be properly nested
4. XHTML documents must be well formed
5. All XHTML elements must be closed

Deprecated Attributes

Almost all attributes that specify the presentation of an HTML document (e.g., colors, alignment, fonts, graphics, etc.) have been deprecated in favor of style sheets. All attributes of the BODY tag are deprecated in favor of style settings for background, text, and link colors. The following attributes have been deprecated in HTML 4.01.

Style Sheets Verses Tables

Since style sheets allow for absolute positioning, the question whether to use tables or style sheets. Actually, the answer depends on what you want to do. If a measurable portion of your audience is using older browsers, then tables are a good idea. Tables, at times, can render more consistently than positioning with style sheets. On the other hand, if your content is properly structured, then the disappearance of content positioning should not significantly influence the content.

Tip

If one wants to plan for the future instead of staying with the past, one should use style sheets for layout and using tables for tabular data. Style sheets give you noticeable advantages over tables. If properly arranged, style sheets linearize better. Style sheets can allow elements to be overlapped. With styling and scripting, one can move elements around on the page, allowing the user to resize them and drag them about as needed. This cannot be done using tables.

Points To Consider When Using Tables

1. Accessibility
2. Compatibility
3. Table Nesting
4. Table width versus screen width
5. Separation of related data

Accessibility

One of the difficulties with tables is that tables can lessen accessibility for the disabled. Using a text reader, each time moving from cell to cell, the text reader will create a sound to indicate a cell change. These text readers are confronted with a confusing series of auditable indicators on a web page full of nested tables and rowspan and colspan attributes that do not pertain to a textual interpretation of the page.

The Web is an extremely useful tool for the visually impaired user. However, keep in mind that these users rely on speech synthesizers or Braille readers to render the text. Careless markup code or markup code that does not have the layout defined in a separate style sheet is hard for such software to deal with. When possible, use style sheets for the presentational characteristics of web pages and use HTML for structural markup.

With tables, a designer should include a summary of the table's structure, and associate table data with relevant headers. This will give non-visual browsers a chance to help familiarize people as they move from one cell to the next.

A designer can follow a few rules to avoid this problem. One rule is to layout the data so that is will render linearly without a loss of meaning. This is to say, the content will not lose consistency because the table is not there.

Use header attributes with cells to ensure that each cell will be clearly associated with any header information. The header attribute associates a cell with header cells by allowing the author to specify a space-separated list of IDs as a value.

The summary attribute can benefit text readers by providing details of the table. Moreover, tables do support the longdesc attribute explaining the table. Some of the browsers do not yet support the longdesc attribute.

Tables that do not have headers because the table does not contain tabular data, it is important the table is organized so it makes sense when linearized. This is to say, if you took out all the table tags, but left the contents otherwise exactly as is, the page should still be comprehensible.

Excessive Table Nesting

To aid in accessibility, avoid excessive nesting. Some WYSIWYG editors use tables as a substitute for absolute positioning. For example, the web page has three columns on the page; the editor will first create a three-cell table. This is not really a problem. However, the editor creates the first column as a menu with ten items in it, and then the editor will then create a nested table in that first cell, and nest ten tables in that table, one for each menu item. Now there are only twelve tables on the page just for the menu.

Avoid nesting where ever possible

Nesting greatly impairs accessibility of a page by making it almost exclusively a visual medium. Most nesting is also unnecessary. In the above example, the menu items can just as easily be stacked with tags for text and constraining the width of the column for images. There are very few reasons to nest tables, although from the perspective of accessibility, nesting may be a better option than spanning columns and rows.

Compatibility

Tables do not necessarily work the same in all browsers. If you skip paragraphs and other types of formatting within the cells, the content will run together into one giant paragraph with some browsers. When using tables, always be aware of how the content will appear without the table and other browsers (including different operating systems).

Table Width Versus Screen Width

When working with a table, one needs to be aware of screen width. If the table is wider than the screen, the user will need to scroll horizontally. Many pages on the Web are guilty of this. If a table is too narrow, then a large gutter next to the table will exist.

There are ways around this. If width is not important, define all widths as a percentage of the screen, and the content will always fit the page. If width is important, then you want to use absolute column sizes. In this case, pick a screen size. Nowadays, the monitor most widely used is 800 pixels wide. This means your tables should be no wider than 750 pixels, if using a fixed table width.

Separation Of Related Data

One problem with an improperly implemented table is that data elements that are related to one another can end up being isolated. An example is using a form. One could create a table with two columns, each with one cell. The first column would contain all the labels. The second column would contain all the data fields. The labels would no longer be associated with the data fields. Instead, you want each label and associated data field in its own row.

Some Additional Notes

The summary attribute is necessary especially for tables used for presentation instead of tabular data. It is important for me to note that almost all the deprecated attributes are available using Style Sheets.

Below is an example of using the style attribute instead of the old element attribute:

Let us say you have a simple two column, one row table and want the first cell with a red background and blue for the other with a 1 pixel border.

Old method:

<table width="100%" border="1" cellspacing="0" cellpadding="0">
<tr>
<td bgcolor="red" width="25%">Content</td>
<td bgcolor="blue" width="75%">Content</td>
</tr>
</table>

Standard Compliant:

<style type="text/css">
<!--
table {
border: 1px solid black;
border-spacing: 0;
border-collapse: collapse;
width: 100%;
}
.cell1 {
background-color: red;
padding: 0px;
spacing: 0px;
width: 25%;
}
.cell2 {
background-color: blue;
padding: 0px;
spacing: 0px;
width: 75%;
}
-->
</style>

<table>
<tr>
<td class="cell1">Content</td>
<td class="cell2">Content</td>
</tr>
</table>

Tip

Even though the Style Sheet method involves more, the benefits of more features and flexibility is worth the little bit of extra effort. Once one uses Style Sheets, the advantages soon become apparent.

Tip

Never leave a cell empty. If you have no content for a cell, place a non-breaking space character (&nbsp;) in the cell.

Wrong - <td></td>
Correct - <td>&nbsp;</td>

Tip

Always put the closing table data tag (</td>) on the same line as the content end.
Example:

Wrong - <td>This is only an example.
</td>
Correct - <td>This is only an example.</td>

Ron Pumphrey of ShadowDezign has been involved with web development for over six years. Ron is currently writing a book on Web Page Development. If you have an idea for an article or what you would like to see written in a book or a tutorial, visit ShadowDezign's Contact page. All comments are greatly appreciated.