The other week, for the first time in awhile, I found myself contemplating table markup/styling for an app we’re developing. I was revisiting this basic question: What’s the best (and most appropriate) way to get tables to show up in our web pages?
When Dan Cederholm wrote his awesome and influential Web Standards Solutions back in 2004, the landscape was a little different than today’s. He noted that if the goal was to display something as a table, the HTML
table element was the only obvious choice:
It would take some severe CSS acrobatics to mark the data up to appear visually like a table [without using the table element]. You could imagine trying to float and position all of the items with crafty CSS rules, only to end up with frustratingly inconsistent results.
– Dan Cederholm, Web Standards Solutions, p. 30
Today that’s no longer the case; the
display:table CSS property combined with any markup of our choice can present a table visually with minimal effort. For example, here’s a simple table of NBA standings accomplished both ways:
The CSS version is certainly more cumbersome, but you get the general idea — CSS
display:table and associated properties let you assign the positioning behaviors of the various HTML
table elements to any markup. And it doesn’t stop with just table rows and cells.
How to choose?
The catch with going the CSS route (aside from the extra amount of code required), is that your markup no longer carries the semantic meaning that makes it recognizable as a table. And so that’s at the crux of how we as developers can go about deciding between the HTML
table element and the CSS
If I’m presenting information or data on screen that is tabular in nature, I’ll use the html
table element, for the same reason I use the
p element for paragraphs,
ol/ul/li elements for lists, and
h1-h6 for headers. First, markup conveys meaning to both people and machines (e.g. browsers, screen readers, search engines), while CSS does not. Second, because those meanings are easily understandable and agreed upon by developers and browser makers alike (for the most part), we get the benefit of helpful default styling being applied automatically without any extra work, as you saw in the example above. In other words, using HTML
table elements to mark up a table is often less tedious.
On the other hand, if I’ve got some content that isn’t tabular in nature, but for whatever reason I want to display with table-like positioning,
display:table and its associated properties might be just the thing. After all,
display:table is basically a css positioning tool designed with exactly this case in mind.
So then, the question becomes one of “am I displaying tabular content or not?” Sometimes the answer is obvious, and sometimes not so much. My mental checklist looks like this:
You’re likely dealing with tabular data if:
- it would make sense to include header cells to describe the content that follows
- you could see yourself wanting to reorder the rows based on values
- it would ever make sense to drop the content into a spreadsheet
- the content only makes sense in a table; i.e. you couldn’t envision another way of displaying it
Making Your Decision
If a few of the above tests hold true, you should likely be using the HTML
table element in your markup. Using HTML elements for their intended purpose helps make the web better, and you’ll be writing less code by not having to write a bunch of extra CSS rules to get your content to display as a table.
If none of the above hold true, you probably have some non-tabular content you’d like to display in the visual style of a table. So wrap your content in some other logical markup of your choice, and go crazy with any and all CSS properties available to display that content how you see fit. Remember, CSS is just a toolkit to help you create visual style — your choices may have ramifications regarding efficiency and browser compatibility, but there’s rarely a “right” or “wrong” choice to be made. So keep
display:table in your toolkit as one of a number of possible solutions for crafting the layout you’re looking for.
And finally, there are very few choices in web development that are black and white, and tables are no different. You might’ve noticed the gap between “if a few” and “if none” — that’s where the gray area comes into play. There are certainly scenarios where you could make a strong case for either method described above. The most important thing is that you are making a conscientious decision based on a solid understanding of the considerations involved.