quick note on tables

I've been slammed at work and not updating this site as much, though I have two biggish posts planned: a followup to my previous discussion about table layout, and the results from a hackathon my company ran the other week.

So I have put out arguments that tables solve more problems than they cause, but the accursed IE8 through up a counterargument... in short it looks like using colspans on rows before rows with items that have set widths may lead to frustrating results. A temporary fix was moving the "offending" colspan to its own table, but I refer my future self to this stackoverflow discussion that describes how setting "table-layout:fixed;" and a placeholder row explicitly setting widths, before the colspan, seems to lead to the correct behavior.

a sinking feeling about floating

I sometimes worry that I'm making what an old boss coined a CLM (career-limiting-move) by publicly declaring my irritation with floating divs vs tables.

My preference for tables is a a hangover from my paleolithic web roots, I'm afraid, but I'm not convinced modern html5-based design provides a solid alternative for flexible grid-based design. Floated divs certainly have advantages (in flexiblity, readability, division of form from content) but "always having things stay where you'd expect them to" isn't among them. 

Case in point: here is some CSS and its rendered result when applied to a wrapper div and 6 children, color coded for your convenience:

<style>
    .floater_wrapper {
        background-color:#cccccc;
        width:160px;
        height:58px;    
    }
    .floater_wrapper div{
        float:left;
        width:40px;
        height:20px;
        margin:4px;
        text-align:center;
    }
    .floater_wrapper div:hover{
        margin:2px;
        border:2px solid white;
    }
</style>

1

2

3

4

5

6

Simple enough, right? Float divs, and add a border when hovered. And in general it works ok... except on Firefox and Chrome, if you happen to have changed the page zoom (like by pressing ctrl-+) up a notch. In that case when you hover over 3 the floating changes, the box 4 jumps to underneath 3, and 5 and 6 get pushed down a row, outside of the box.

I'm not sure exactly what's going on, in terms of why the "4" thinks "2" is lower than "3" and so it floats against that-- I assume the screen zoom is putting in rounding errors. This particular case is easily remedied by not changing the margin when hovered and giving the non-hover state a transparent border, rather than assuming a 2px border plus a 2px margin is the same as a 4px margin.

So this case had a simple fix, but the non-intuitiveness and obscurity of the error (in terms of the page zoom) gives me pause. A radical change in structure like that is just not something you would have seen in a table-as-layout solution.  Just to get it out of my system, I'd like to write a few more advantages caveman-tables-for-layout have over floating divs. (Which is the fairest way of putting it, I think: people who say the argument is "tables vs css" are being grossly unfair.)

Eric Meyer, in 2009, put it pretty well:

All this is why the old “only use tables for layout” argument keeps coming up over and over: strip away the overheated rhetoric and obvious link-baiting, and you find the core of a real need. Because as powerful as CSS can be, table cells do certain things very easily that CSS makes very, very hard. Cells stretch vertically, keeping equal heights as a matter of their intrinsic nature. They stay out of each others’ way, while still being allowed to sit next to each other and use any sizing dimensions. They tie their layout to their parent elements, and vice versa.

I'd love to hear if the situation has changed much since then.

I can see the advantages that floated divs can have: like in today's example I didn't need to pollute the numbered divs with table structure layout, and programmatically it would have easier to just keep on adding in divs, rather than having to coordinate the row structure. (and yeah yeah yeah, tables are for tabular data and using them for layout is the anti-thesis of proper html5 semantic thinking.)

But on the flipside, the wrapper in this example had a fixed height, in part because a container div will collapse if all its contents are floated (hence things like the clearfix hack... and don't get me started about some of the disgusting stuff I've seen to get columns to line up!)

Finally, beside my love of colspans and rowspans and what not, it's a lot easier to throw a "border" onto a misbehaving table you're trying to construct than to get a visualization of errantly interacting floating divs!

I'm swimming against the tide of design history here, I know, but until I learn of a better way to get grid-like behavior on a webpage, tables are going to be part of my web design arsenal.

(Quick followup as I ponder this a bit more: I do realize responsive design is generally a lot harder with tables, because of the mix of form and content. Most of what I really count on tables for, though, is not in the "whole page" style of layout, but for individual smaller widgets, where you really don't want things jumping around, and for them to keep their general relative positions. That's actually one of the paradoxes of responsive design: usually you want layout things to stay the same, no matter how the content changes, but with responsive design you finally want things to shift when the content seems to big for the space allotted...)