Tables Are Bad, M'Kay?

Tables Aren't Bad.

Somehow, in the Cliff's Notes version of the great InterWeb Revolution of 2001, the story has been reduced to "All you need to know is that Tables are Bad, now". I am not sure how or why this became the take-away from the uprising, but it's something that gets back to me three or five times a year, it seems.

Don Novello's character, Father Guido Sarducci used to have a Five Minute University where he taught everything that a college graduate knew five years after graduation, in only five minutes. Want a Business degree? "Buy low, sell high". Want an Economics degree? "Suppy and Demand". Somehow, we've become a culture that worships the summary blurb more than the total package. I fervently pray this has so far escaped the fields of Aviation and Medicine.

"Oh? I thought Tables were bad?" seems to be offered up more than any other piece of failed conventional wisdom about the Web, the last several years. It comes up more often than "You should be able to get to anything you need in three clicks". It comes up more often than "browsers don't support CSS well enough to really depend on it". It comes up more often than "everybody uses Internet Explorer".

Tables aren't bad. Using Tables for layout is bad.

Tables came into the world to save us all from using non-breaking spaces to line-up our data into rows and columns. As you (may/should) know, Web browsers have been trained to ignore multiple spaces and represent them as just a single space. This plays Hell with those of us who learned to type in the Olden Days, who were told to always end our sentences with a period and two spaces. The online alternative, then, was the non-breaking space,   or  .

Non-breaking spaces, well, don't "break". If you string thirty of them together, you will get thirty spaces. Using the regular space-bar character, you would get only one. And this was fine(ish) for the first few years of the Web. But a system like this breaks down if you increase or decrease font sizes past a certain limit. And it takes more time to fill out a page, as you are actually having to download the spaces rather than the next data item in the row. [Space] [Space] [Space] [Space] [Space]Not good, huh?

And so Tables were released upon a grateful Web. Now we could corral various data and line it up into grids like we were used to seeing in so many reports and schedules and other printed materials. And because we could change the fonts, colors and background colors in Tables, just as we could with other HTML elements, some very artful Tables sometimes were the result.

But the commercial end of the Web was heating up about this time, too. And those people are famously, ruthlessly, unaccountably creative. Once they learned you could put anything into a Table, they did. Form elements were more easily aligned inside Table cells. Placing images inside Table cells meant you could precisely control where and how they appeared, and that quickly became The Way Things Were Done. Probably it had to happen, and eventually it did: At some point someone put a Table inside a Table. Jesus wept.

It wasn't that the Designers of the day were ignorant of Tables' original purpose. It wasn't that they did not care about the drawbacks of using Tables. It wasn't that they were jerks. It was just that Tables were all we had, back then. If you wanted a Web page that looked like your corporate stationery, you had to lay it out in a Table.

Today we are not bound by the limits of Tables. The border attribute of Tables can be set to "0" or "1" or some other number, giving you no border, or a one-pixel border, etc. But using CSS, we can style each individual side of the Table, and have different values for the border of the Table itself, and the borders of the Table Data cells, Table Rows, etc. But CSS provides even more freedom by letting you break out of using Tables to just place images "over here" and navigation "over there". It's an important improvement.

But that doesn't mean that Tables are bad. If you are representing tabular data, they are still and always the best choice. A listing of classroom schedules would contain a class name, "ECON101", and the professor's name, "Wilson" and the days of the week the class is taught, "MWF" and the time, "1:00pm-1:50pm" and where, "214 CBA" and how many credit hours the class is worth, "3". Placing this kind of information in a paragraph, one time, is hard to understand, but packing all of the information into a paragraph would be horribly confusing.

ECON101, Wilson, MWF 1:00pm-1:50pm, 214 CBA, 3. ECON102, Harlow, TTh 10:00am-11:50am, 235 CBA, 3. ECON201, Wilson, MWF 10:00am-10:50am, 214 CBA, 3. ECON211, Barnett, MWF 9:00am-10:50am, 311 CBA, 3.

*Whew!*

You could style that wad into rows and columns, but they would be very fragile and would easily break if the user adjusted their font size.

Much better to see it all in the rows and columns we are all so comfortable with.

Please keep scrolling, to see the real table. Blogger is acting up on me again and for some reason is adding a huge amount of space between here and the table:

ECON101	Wilson	MWF	1:00pm-1:50pm	214 CBA	3
ECON102	Harlow	TTh	10:00am-11:50am	235 CBA	3
ECON201	Wilson	MWF	10:00am-10:50am	214 CBA	3
ECON211	Barnett	MWF	9:00am-10:50am	311 CBA	3

Much nicer, right? It's what we are used to. It's what we are expecting. It's the right tool for the job. If you have tabular data, use Tables.

By the way, a special tip of the hat to Blogger, for not allowing me to clean up all of the room between the here-comes-a-real-table text and the table itself. Nice work, guys.