A cursory Google search will return around 8 million results, most of them waxing long and poetic about the various failings and flaws of table-based layouts (although one notable site is hilariously short). To be honest, there is a great deal of truth to these articles – but not quite as much as some would have you believe.Tables are for tabular data. Using tables for layout is evil. If you use tables for layout, YOU are evil. Don't do it. Don't do it ever.
DON'T $*&^%ing DO IT!
But tables are bad, right?
Yes and no. For tabular data, no, of course they're not bad. That's why tables are there in the first place. CSS can do an excellent job of styling a properly-formatted table and the table structure provides a nice scaffolding for javascript calls.
Most of us know that. What we're talking about here is using tables for non-tabular data, or layout. Yes, using tables for layout.
So when should you use them, smart guy?
Sparingly. Let me give you a very recent example.
This fairly small piece of the new home page for a client was done with a table. Why? Because I lost almost nothing and gained quite a bit.
The bad: what did I lose?
Well, I lost the ability to arbitrarily restyle that section without touching the page code. That much is obvious and is a true downside – though in this case I gauged it to be a minimal one. I also lost, in a puritanical way, a perfectly semantic page: dig into the code and you won't find a nice little list, you'll find three rows with four cells apiece.
What would others say I lost that I didn't actually lose?
I Lost SEO
Wrong. The nugget of truth here, and it is only a nugget, is that a pure CSS layout forces you to write better markup. That could be true, but nothing is stopping you from writing a well marked-up table section. Search engines don't care about tables, or your CSS.
Don't believe me? Check out Google's Webmasters/Site Owners documentation and search for tables, or CSS. Then download this PDF and do the same. Then, for giggles, go back to that Google webmaster page and view source. Good stuff, huh?
It's not accessible!
You will probably hear some accessibility advocates say that layout tables are a bad idea, and that CSS layout techniques ought to be used instead. ... People with all kinds of disabilities can easily access tables, as long as the tables are designed with accessibility in mind.
https://www.webaim.org/techniques/tables/#cl
It's completely true that a totally table-based layout can mess up screen readers, because the reader will traverse across rows and your layout may have nothing to do with that. In my example above though, you know what the difference is to a screen reader between a table and a ul? Nothing. Not a single thing.
Screen readers don't ignore tables; if they did any sort of data-centric site would be meaningless. What screen readers do is make a judgement (generally based on the presence of a <thead> section) about whether a table is being used for data or for layout. Upon finding a table used for layout the screen reader does exactly what a search engine would do: ignores it and reads like it isn't there. There's a great article on WebAIM about writing accessible tables, and how screen readers behave when presented with a table. Whether you agree with me here or not you'd do well to read that article, if only for your data tables.
Longer page load time.
Wrong. A completely tables based layout would, in fact, be a larger page. That could be a bad thing, even if these days bandwidth is so cheap as to be almost meaningless. A sufficiently complex table would be a lot to parse and could slow down a large page – but we're not talking about a totally table-based layout (at least I'm not – if you are, well, we should talk some time). For small sections the bandwidth and load time difference is irrelevant, and in fact a sufficiently complex chain of CSS selectors can bring IE6 to its knees.
Alright, what do we gain?
Speed of development and testing. That table above took me about two minutes to write, and the equivalent CSS would have taken...maybe slightly longer but not by much. What pushed me over the edge though was the QA time I'd recover.
Let's not kid ourselves – we all develop in the shadow of IE6. IE6 hates CSS-based layouts, even IE7 managed to omit a handful of really useful selectors. I could have written that little section in CSS, and in everything from Firefox 2 up to Safari 3 and even IE7/8 I would have had almost no problem. And then I would have wasted half an hour getting IE6 to work the way it should.
The website Give Up and Use Tables I think maybe paints with too broad a brush but they are definitely on to something. If it takes more than an hour, say, to get your layout working in IE6 and a similar table based element would solve the problem for you in 5 minutes, what are you doing? In these cases you won't lose SEO, you won't lose accessibility and the hit to page load time is irrelevant. Are you just faffing around with CSS for fun? Be practical.
Bring it on!
I have no illusions about how some people, maybe the ones in my office, will feel about this. CSS is sacrosanct, and advocating a departure from the purity of CSS is tantamount to blasphemy. I'll be the first to admit that I want to do everything in CSS. I love CSS. It's an elegant means of styling markup, and in a perfect world we could use it for almost everything on the web. We don't live in a perfect world – we live in a world of deadlines, and old browsers, and frustration, and ill-supported standards.
Tables are not the enemy. They like so many other things are a tool we can use for good or ill. Used sparingly tables can save you a lot of headache and you'll sacrifice (next to) nothing. Use common sense. Be practical. It's possible to use a table now and then and not be a terrible person.