The case against tableless CSS

Tableless CSS has become an extremely trendy mechanism. However I find that it is quite often an albatross to the construction process. This is true because CSS is not a language that operates in aggregation. CSS elements "Push" and contain each other in a kind of stateless struggle; there is no such thing as an array structure in CSS for instance, nor an eplicit way to say element X is to the left of element Y. All of CSS's markup is individualistic. You cannot use CSS to directly state, "Put me, him and him on the first row; I want to be twice as wide as he is and half as wide as the other guy." This, however, is a natural part of a table's definition.

Tables in HTML will always bloat to contain all the content within their cells, regardless of the markup. For instance, barring use of CSS for bizarre effects, no matter what definitions you apply to row or table markup, if you put an image in a cell that is 400 pixels wide, every cell in that column will be 400 pixels wide. Given that you are often unsure of exactly what is to go in a specific cell, this is a very useful safety valve.

Plus, tableless CSS is HARD and you can SCREW IT UP. Becuase the style and the instantiation are seperate, one can easily go into the CSS and edit it slightly, not noticing that a (fake) table in another page just fell to pieces. And by fall to pieces I mean elements in improper order, and a wholly unreadable layout.

Tables, on the other hand are nearly impossible to accidentally screw up. As long as you have the table/row/cell nesting right, at worst you can make things look a little funny. Thats a pretty low learning curve, and a pretty short route to guaranteed results. You can put wrong values into the properties, or use TH when you should be using TDs, or even (though you really shouldn't ) leave out the closing tags for cells or rows and you will still get a matrix that is basically the right shape, and is readable. CSS is very much less forgiving and requires much more careful cross-browser proofing.

The case against tables is that they are slow loading and require too much markup; worse yet, their styles are not globally maageable. This is frankly, crap. You can assign a class to the governing table and use CSS on row and cell elements to apply a huge amount of tactical styling (H/V alignment, font, color, margin, padding, border). To accomplish the same thing with divs you have to assign classes to each div in the set -- some of the divs must function as rows, some of them as cells (though to be fair you can also do column/cell arrangements) and that pretty much leaves you just as bulky as your original table markup. Plus tables are much more self-documenting than tableless CSS.

And while, honestly, the divs do load a bit quicker, I have trouble believing that the time saving is so drastic as to overwhelm all other considerations. There is a lot of other YSLOW-related action that has mucch greater impact on your page delivery than your choice of table technologies.

The greatest argument against tableless CSS is that there is a level of complexity at which even the tableless crowd will say, "Yes, of course for this application, you would want to use tables." There is, on the other hand, no level of complexity that will drive the table people to say, "We've done all we can with tables. Now we need to stop using tables and switch to tableless CSS." If the robustness and reliability of tables are useful in the extreme, then in my opinion, they are reliable enough to be used nearly everywhere else, too. Or at least, everywhere that a grid pattern is the desired result.