What's the problem with CSS Tables? I mean really?

[philtune]

Oh there’s so much noise and so little signal. In response to a year-old screencast on “Don’t Overthink It Grids”, I commented asking about drawbacks of display:table layouts citing my own benefits I’ve gained: https://css-tricks.com/video-screencasts/115-dont-overthink-it-grids/#comment-492647. I’ve not read anything satisfactorily pointing out deal breaking flaws. Chris posted “CSS Tables Are Not A Solution” – https://css-tricks.com/css-tables-are-not-a-solution/ (again, from 2009… I’m behind on my reading a bit) – which cited Eric Meyer – http://meyerweb.com/eric/thoughts/2009/02/17/wanted-layout-system/ – stating “Turning a bunch of divs[…] into table-role boxes is no better than just using table markup in the first place, and it’s arguably worse. ” But WHY is it worse? Peter Wilson commented (2009) “I’m not ready to throw out CSS Tables yet[…] My main concern is div bloat, if experimentation shows that bloat won’t occur, then I may use CSS Tables.” – https://css-tricks.com/css-tables-are-not-a-solution/#comment-52123.

I may just be really behind on the argument, but Google only seems to pull up old articles and many of display:table’s detractors state philisophical issues with it instead of citing concrete issues like performance, semantics, compatibility or CSS bloat. Eric Meyer does mention “[Using table-role boxes] means you’re doing your layout in a highly source-order-dependent fashion”, which is a good arguement if you’re looking to layout content with a different source-order than is obvious. But a lot of design, right now, is dependent on source order unless you break out some Javascript (and flexbox if you’re only supporting newer browsers). Peter Wilson mentions div bloat, which really doesn’t have to be an issue.

I my comment mentioned above, I cited just a handful of benefits I’ve seen from using css tables and for many of my projects for my company they work wonderfully sans hair pulling. They are semantic (divs and html5 elements), they are succinct–the code isn’t bloated, the css is very simple in regards to layout–, they would seem to be just as performant as anything else. And as for the source order, I’ve used direction:rtl to scooch around that issue with good results. (I’ve not actually seen or read of other people using this, so if this is bad practice lemme know.)

Any thoughts? Links? Up-to-date quotes (sorry for my ancient references)?

[philtune]

I’m thinking about the alternatives, and they seem to be worse.

First is floats. We’re talking about layout, not content. When I think of floating elements, I think of images, figures, and aside content flowing around and being wrapped by article content. Floats have a very specific purpose and (for the most part) grid layouts and wireframes should not be included.

Second is inline-blocks. Grids are not a collection of inline elements. They are fixed (albeit perhaps flexible) until @media queries dictate otherwise. Inline and inline-block elements are meant to flow around each other and respond to container sizes. Trying to purpose those display types for grids just doesn’t. make. sense.

When you map out your wireframe on paper or desktop, what do the wireframe grids look like? They look like TABLES. For the most part, they ACT like tables. Tables have stability, predictability, FLEXibility (by default, no %’s needed). If you have a cool new layout that doesn’t need or work well with those qualities, consider my comments moot.

[Author]

Posts