The most popular layout is three columns all the same height with a header and footer. The CSS is so hard that articles about it have titles like “One True Layout” and “In Search of the Holy Grail.” Yet this is a way that throws zero bugs in all browsers and takes only a hundred bytes — a fifth of any other method. Even so, many web designers frown on that one because it uses a <table> tag.

This tag is accused of mixing semantic and presentational markup, obstruction of redesign, and tripping up the blind, the browser-impaired, and Google. Furthermore, the table has a tainted history as a known accomplice of the font tag and spacer GIF in the 1990s. In those dim times it acted even worse, eating up bandwidth as it nested and spread like the Plague. Designers who have come out of that dismal period have, understandably, a bad taste in their mouth for the table — even if it still has its uses. So now the table is confined to a life of serving only “tabular data.”

Totally tabular tables

I fought to avoid the table at all costs, embracing instead the <div>, the <h1>, the <ul> — anything but the table! But every time I had to make a three-column layout, the gentle table tempted me from afar. So, with a looming deadline and literally a guilty conscience, I succumbed more than once to the table’s easy charms.

Now at my company I am both a web developer and a technical writer. The writer in me loves etymology (the study of the roots of words — not to be confused with entomology, the study of insects). It helps me pick apart jargon and make it understandable to others. It doesn’t take an expert, however, to notice that the root of tabular is table. So, saying “only use tables for tabular data” is like saying “only pour water on things that are wet.”

It was this semantic loop that piqued me to reinvestigate the scene. So while we’re on the topic of semantics, let’s look again at the first charge.

“Mixes semantic and presentational markup”

The separation of semantics and presentation is a false dichotomy.

The other tags aren’t that pure

If you wade in etymology long enough you begin to see that many words get their meaning through metaphor. For example, sarcasm literally means “flesh-tearing” (kind of makes you think twice about saying something sarcastic). This is true even for abstract and ethereal words like spirit (“breath” or “wind”) and desire (“to wait on the stars”). Even abstract means “taken away,” and ethereal comes from “ether,” which was once believed to be a real substance.

So let’s look again at the HTML nobility and see where they come from.

Their presentational roots couldn’t be more palpable.

The table isn’t that impure

You may have noticed that I presented the information about the tags in a table. (No, a table’s ability to contain the other tags is not my argument.) Even the strictest member of the W3 would say my use of a table in this case was fair. So what is a table, anyway?

A table shows relationships. In fact, the mathematical equivalent of a table is called a relation. The foundation of relational databases like MySQL is the relational model, such as is described in the writings of mathematician E. F. Codd. They are called relational databases not because you can relate one table to another (as many think), but because they are databases of relations (tables). There are other kinds of databases: those based on the hierarchical model and the network model.

Each cell has a certain relationship with all the other cells in its column. They are of the same kind. Each cell has another relationship with the other cells in its row. They are of the same topic.

It is like the way an <h1> or <h2> tag is to the <p> tag right after it. The heading holds a short summary of what the paragraph is about. As for the <ul> tag, isn’ its meaning that all of the <li> children that it bundles are related?

Furthermore, just as <ol> tag implies that its order matters, wouldn’t the table mean something different if you changed the order of its <td> tags? Or even if CSS could move one cell up and another cell down and another one around, why would I want to? That would change the meaning.

Relationship is meaning

A document’s structure is the relationships among its elements. The relationships hold it together. You might say then that relationship and structure are synonyms. And as you can see, all these tags signify different relationships. That is their semantics. Since a table, just like the other tags, shows a relationship, the table tag is semantic.

So, when you intuitively want your logo to stretch across the top of your blog site, and then have below it a column for main links, beside it a column for an article, and beside that a column for article archives, and finally a footer to wrap things up, that says more than if you just had five divs in a row. Wouldn’t it in fact change the meaning if you moved what’s in the header to the bottom, the article to the far right, and the content of the footer to the big middle section? Wouldn’t that be weird?

Yet this “ability” to shuffle layout is exactly the reason the standardistas give for keeping everything in divs. But moving things changes meaning. It’s not just finishing touches or designer fluff, (the jurisdiction of CSS). Position has meaning.

The position of the three middle parts beside each other shows that they have a relationship with each other that is different than the relationship that each has with the header or footer. They are all involved with the meat of the site. Putting your header in a td above the three cells and giving that td a colspan of 3 is actually adding meaning to your page. The same goes for your footer.

Without CSS, the structural markup of the top td covering the three below it has more meaning than if it were just a div. And the structure of a footer td below the three tds yet spanning all of them as if it was somehow tying their ends together — isn’t that what the content of a footer is for? So, colspan="3" carries meaning.

I think that’s enough philosophy for now. Let’s move on to the next charge, which is more practical.

“Obstruction of redesign”

The argument that a table constrains you to a certain layout is true. Maybe the Democratic party likes your blog so much that they are subsidizing you and you don’t need a third column for ads anymore. Or maybe your design client thinks that the content on the right should actually be the main navigation and the left links were secondary after all. You can’t flip table columns with CSS.

Now aren’t you are stuck in the revision nightmare of the 1990s? Don’t you have to go through hundreds of HTML pages and change each one, when you could have used divs and made a change in just one CSS file?

Databases to the rescue

What were you doing hand-coding an HTML page for each article anyway? Databases have been around since the 1960s. If you’ve never used a database before, this is what it would do for you: Even though you have 500 articles on your news website, you do not have 500 HTML pages. You have one. It looks something like this:

<html>
    <head>
        <title>%title%</title>
    </head>
    <body>
        <h1>%title%</h1>
        <div>%body%</div>
    </body>
</html>

(Yes, this template is simplified for the sake of clarity.)

Then you have a database table like this:

In the template, %title% and %body% are variables. The web site inserts the title in place of %title% and the body in place of %body% every time a user requests a page. The text of each is kept in the database. So if you do change your layout, yes, you would have to change, remove, or add to your table tags. But you still change just one file.

“Not accessible”

Tables are charged with being not accessible to screen readers, lightweight browsers, and search engines.

Screen readers

A screen reader should go from td to td, from top to bottom, left to right, just as it would go from div to div from top to bottom. Since position means something, if you used a table, you likely have ordered your table cells in a logical order, even the same as you would have ordered the divs. Screen readers should also allow the user to press skip to jump ahead to the next box if it’s obvious that the current box is a long-winded list of links.

Lightweight browsers

This is how the text-only browser lynx sees this page.

This is how a browser with CSS turned off sees it.

End of discussion.

Search engines

If, for the sake of search engines, we ought to use the most specific HTML tags and furthermore add descriptive class names to them, why does the most successful search engine in the world use tables all over the place and class names like g?

Google’s Director of Search even criticized Tim Berners-Lee about the idea of a semantic web. And all you have to do is read some of Google co-founder Sergey Brin’s research papers, such as What Can You Do with a Web in Your Pocket? to see that we vastly underestimated search-engine programmers.

Go forth and use tables

Am I saying we go back to lots of nested tables, spacer GIFs, and font tags? No. What I hope to do is free some web designers from being too legalistic, and even wrong, about what the table can be used for.

Even though I am a long-time believer in “the right way is often the harder way,” I also think that constant difficulty may be a sign of a bad fit. If for years you’ve failed to jam a round peg into a square hole, while a square peg slides in ever so easily, maybe it’s because the square peg belongs there.