By: Zoe Gillenwater
Page 1 of 4
This is the seventh article in the Semantic (X)HTML Markup series. Before we begin, you'll want to read the previous articles:
- Semantic (X)HTML Markup: An Introduction
- Semantic (X)HTML Markup: Headings and Paragraphs
- Semantic (X)HTML Markup: Creating Emphasis
- Semantic (X)HTML Markup: Blockquote, Q, and Cite
- Semantic (X)HTML Markup: Structuring Lists
- Semantic (X)HTML Markup: Styling Lists
In this article we'll learn how to use perhaps the most misused semantic element: the table element. Like all the other (X)HTML elements we've learned about, there's a right and wrong way to use tables. The W3C created the HTML table model to "arrange data — text, preformatted text, images, links, forms, form fields, other tables, etc. — into rows and columns of cells." They specifically state that tables are not to be used for layout:
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.
The accessibility problems of layout tables are why avoiding tables for layout is checkpoint 5.3 of the Web Content Accessibility Guidelines (WCAG). Using tables for layout can also rob you of one of the greatest benefits of CSS: its flexibility. Using CSS, the entire look of a site can be changed with a few edits to one style sheet. If complicated, nested tables were used instead, creating even minor layout changes can become a huge undertaking.
In recent years, many web developers have begun listening to the guideline to avoid layout tables and now use CSS to lay out their web pages. Instead of fitting sections of the page into rigid table grids, this new layout method involves placing content (marked up with semantic headings, paragraphs, and lists, of course) into div elements for each section of the page and then using CSS to position and style these divs.
Unfortunately, many forgot that tables still have a valid and valuable place in web design and tried to get rid of tables in their designs altogether. This is not the correct approach either. The table is still a valid (X)HTML element, and when you are trying to mark up tabular data, it is incorrect to use anything else!
Since the Semantic (X)HTML series is focused on how to use and mark up semantic elements, not about how to not use certain elements, this article will focus on the proper use of tables for data rather than on how to create layouts without tables. For information on using CSS instead of tables to lay out your pages, start with Flowing and Positioning: Two Page Models, Float: The Theory, and The Box Model Problem. Once you understand these concepts, you should be ready to undertake a CSS-based layout, such as the one detailed in Stephanie Sullivan's Creating Fluid Pages (Part Two).
Using Tables for Data
So tables should still be used to mark up tabular data, but what is tabular data? Tabular data is information that has a two-dimensional relationship. Let's take a simple data table:
|Vice President||Jane Doe|
|Executive Secretary||Mary Thomas|
The data in this table has relationships in both the horizontal (title-name pairs) and vertical (lists of titles or names) directions. Although the values do not have to be laid out in columns and rows, they make sense in columns and rows. When you are trying to decide whether or not to use a table for a section of content, think about whether you could put it into Excel or another grid-based program. Regardless of whether or not you want it to appear in a grid at the end, could it fit in a grid with descriptive headers labeling both rows and columns? Notice also that tabular data doesn't have to be numeric. It can be any sort of text or even images, as long as it has a two-dimensional relationship with the data around it.
If you've just read the Structuring Lists or Styling Lists articles in this series, you may be tempted to use a definition list to mark up the data shown in the table above. While I agree that a definition list would be acceptable for this example, I think a table is a better choice in this case. This is because of the two-dimensional relationship that the table provides. As a table, you could read it across, pairing the names with the titles, or you could read down the columns to read the entire list of titles and names separately. Using a definition list, your data is arranged in only one dimension – you must read a title, then a name, a title, then a name, instead of being able to read down the lists. All you have is the pairs, not the separate lists of names and titles. A table creates richer relationships between the data so that user agents can interpret it and read it in various ways.
Conversely, there are times when a list might be better suited to your data, as the previous articles on lists illustrated. It's up to you to evaluate the relationships between your data and decide which (X)HTML element is most well-suited to your content.