It’s been more than a decade since the call to abolish table-based layouts was started. Many, if not most, designers and developers have come over to the CSS way of doing things (or at least doing it most of the time while occasionally resorting to a table layout when they couldn’t get the CSS to work.) Mixed in with the pragmatic use of tables is the occasional person pointing out the advantages of table-based layouts.
Tables do things when laying out that CSS designs with floats and padding and negative margins haven’t been able to duplicate with the same simplicity: dynamic grids, rows that are all the same height, and vertical centering. There are grid systems, and frameworks that have handled this problem for awhile but they have their warts. CSS-based tables are a good solution to this problem, and have a lot of other benefits. But even then I’ve heard angst about CSS-based solutions (frameworks or CSS tables) basically being the same amount of work and angst as a table for the same result.
Here’s a colleague (Greg Rewis) of mine complaining about the main angst of all of these solutions:
On the other hand objections to using tables are usually based on semantics, SEO, and accessibility:
- tables are for tabular data
- tables in layout are incredibly hard for screen readers to deal with
- table markup adds a lot of cruft to markup
The problem with these issues is that for many people they just aren’t compelling enough. Correct semantics is a lofty goal, but it’s not a goal that clients care about. Accessibility takes a back seat because most of us never bother to fire up a screen reader. Cruft is usually seen as bad, there are other ways to improve page performance and SEO, so this argument sometimes helps but not enough.
Therefore, I’ve added a new reason not to use tables focusing on the current zeitgeist around responsive design:
Once you go table, you cannot go back.
Once you wrap your stuff in tables you cede a lot of control of the presentation to the browser. And most browsers don’t linearize info in a table well because by wrapping it in table markup, you’ve effectively said “don’t linearize this content”. So if you are going to display this info on a mobile device with a smaller width you get scrunched content that is hard to read. Either that, or the mobile browser keeps it wide, but allows you to horizontally scroll, which as you know is a fate worse than death.
Live Demo: Table Design
Your first attempt to deal with this is to handle this with floats and padding and whatnot. You set everything to float left, so when the screen contracts, things slip under each other. This works very well if you know or hard-set the dimensions of your content beforehand. Otherwise you end up with weird outcomes and odd configurations of your grid. Even if it does work well, typically you’ve needed to add extra structural markup to make it work. Adding the cruft that not doing tables was supposed to take away. And it’s all div’s so it gets hard to keep track of where you are.
Live Demo: Float Design
Ideally, you want something that acts like a table when you have a wide screen and acts like simple block divs when you are on a small screen. So you take some good semantic HTML, combine it with CSS tables and boom, you have a layout that acts like tables when you are wide, and acts linear when you are small. It also lacks the weird layout issues you get from floating.
Live Demo: CSS Table Design
There are issues with this approach as well. IE 7 and below doesn’t support it. So that is something to contend with. I choose not to. In browsers that don’t support this, it just looks like the linearized version, which I’m pretty cool with as it is suboptimal, not broken. I’ve also seen a weird issue with it not laying out things correctly when I resize the screen. (If you refresh after resizing, it draws it correctly.) Still tracking this down.