/* Column layouts */
.column { float:left; overflow:hidden;}
.columns { margin-bottom:20px; padding-top:10px; }
.three.columns .first { width:200px; padding-right:20px; }
.three.columns .second { width:200px; padding:0 20px; }
.three.columns .third { width:200px; padding-left:20px; }
.two.columns .first { width:300px; padding-right:20px; }
.two.columns .second { width:300px; padding-left:20px; }

This lets us code the XHTML like this:

<div class="three columns">
     <div class="first column">
         Column 1
     </div>
     <div class="second column">
         Column 2
     </div>
     <div class="third column">
         Column 3
     </div>
<div style="clear:both;"></div>
</div>  

… which is pretty nice semantically.

As of June 2008, this notion is so deeply buried in the conventional wisdom about Web page design that just about nobody ever thinks about it anymore; the idea of using a table for anything other than Tabular Data is met with scorn and derision from developers.  And so the lowly <table> tag sits alone in the lunchroom, friendless, with nobody to talk to except its perpetual hangers-on <td> and <tr>.

Now of course, we don’t use tables for layout at White Whale.  Ever.  How could we?  It’d be like driving an SUV, listening to a Zune, or voting Republican— it’s something cool people just don’t do.  We (as a company) couldn’t design a site with layout tables and look at ourselves in the morning.

But I don’t like conventional wisdom, and as a result I often find myself thinking about tables— in particular, how there are some things you can do with <table> that you can’t do with <div>, no matter how hard you try.  (At least across all browsers, and without using Javascript.)  

What makes it worse is that these are some REALLY, REALLY SIMPLE THINGS.  Like attaching a footer to the bottom of the viewport, or the bottom of the content area, whichever is appropriate.  Like displaying two columns of content, and having the width of the two columns be determined by whatever makes sense for the amount of content they contain.  Like setting a content area at, say, 10% width, unless your content contains a word like “supercalifragilisticexpialidocious,” in which case the content area won’t get any narrower. 

Now, I know not many people read this blog, but if this were a serious CSS design blog (which we modestly hope it someday may be), I’m sure we’d get commenters tossing out <div>-based solutions for all these cases.  I am pretty good at CSS, but I’m certainly not a black belt, and it wouldn’t surprise me at all if there are some decent solutions out there.  But here’s the thing—all this stuff is built into <table>.  And all browsers get it.  Automatically.

<table> is a relic from a simpler time, when there was a general idea that common sense ought to govern how browsers render Web pages.  <div> is a creature of the present— all it knows is rules.  It knows nothing of “common sense.”  As a result, much of CSS design— even the high end stuff— becomes an attempt to duplicate in CSS behavior that comes naturally to a <table>.

Here’s a quick site I did last summer for a kickball league we started in Oakland.  If you resize it a bit, making the page really small, really big, etc., you’ll see how there’s a 250px wide side column, a title at the top that changes color as it crosses the color line, and background images pegged to page bottom.  I must have spent four hours getting that to work in CSS, without success; once I decided to use a table, I coded it in five minutes.  

But of course, that’s a personal site; we could never have done that for a client site. Now, those of you who know us know that Donald is the most standards-obsessed Whale; he handles all our initial CSS buildouts once designs are approved.  We often have conversations like this:

Jason:  Why isn’t the buildout done yet?

Donald:  Grrr!  I’m having a hard time getting (insert awesome design feature here) to work in IE6.

Jason:  Well, you know, you could use a table for that.

Donald:  No I can’t.

Jason (knowing D hates when I ask this):  Why?

Donald:  Because tables aren’t accessible.

Jason:  Are you suggesting that an audio browser isn’t able to interpret a one-row table?  Do you suppose, then, that this page, which uses a table for layout, is inaccessible?

Donald:  It’s just not best practices.

Jason:  Well, if it can be rendered by a screen reader, and it works across all modern browsers, and actually involves less code than a CSS solution, how is that not best practices?

Donald:  People will laugh at us.

Jason:  OK, fine.  But if we don’t get it solved by tomorrow afternoon, I’ll use tables and code it myself.

And then Donald stays up all night and figures it out.

The fact is, I’m fine with <div>; I just wish sometimes it had some common sense.   And just like a former cigarette smoker might occasionally step out behind the house and indulge in the guilty pleasure of an old bad habit, I reserve the right to use tables occasionally in my own work.

Getting these PNGs to actually be transparent is no longer a major issue—we’ve used a few different approaches over the years, but settled on Angus Turnbull’s iepngfix.htc as the most straightforward drop-in solution out there. The way it works is just really smart.

But while building out some recent client projects, we just couldn’t get it to catch. We checked and double-checked the file paths, and re-exported the PNG images, and finally copied a working example from a live client site, but nothing seemed to do it. Because IE has no decent debugger, I removed the conditional comment to see what I could learn in Firebug.

It turns out that our staging server sends the .htc file as text/plain, while the working client version was serving text/x-component. Changing out server config to mimic this fixed the problem. Later, some Googling revealed that the release notes for the newest beta version address this (and even include a PHP solution that serves the file while sending the correct headers).

There are still a whole host of limitations: no repeating images, weird layering glitches that happen even in IE7, and really bizarre link clickability issues. But iepngfix gets far enough to solve 90% of the problem.

At White Whale, we’re of course always thinking about code efficiency: less queries, less code, fewer requests, et cetera. And much of this on the design side is rote best practices (semantics, accessibility, compatibility). But I still find myself sweating more nitty-gritty details, so I was fascinated to see jpsykes’ analysis of this one. The question boils down to, “How specific should I get with CSS selectors?”

We have:
#header #navigation .portal  { font-weight:bold; }
vs.
.portal { font-weight:bold; }
I’ve leaned toward the first on a gut feeling; .portal will only ever appear in #navigation in #header, so why not tell the browser where to look? But intuition is wrong in this case. Check out the graph (again, via jpsykes):

Giving more selector specificity causes performance hits across all the major browsers. What’s happening is that the browser actually starts at the right-hand side of the selector and searches backwards. So it finds all instances of .portal, then climbs up the DOM to make sure it’s in #navigation, then filters again for #header. (You’ll see that FF3 seems to perform best overall, but that’s a little misleading for reasons a commenter notes here. Check out the results with a better control.)

Interestingly, the opposite effect is true for JS frameworks. Their selector implementations — we use jQuery at White Whale — tend to process the selectors from left-to-right: first finding #header, then looking inside it for #navigation, and then inside that for any instances of .portal. So those work best when coded with some specificity.

It’s important to note here that we’re talking fractions of a second on a page with 20,000 test elements. So until we start serving 20,000 database records on a single page, our best practice will be whatever makes it easiest to keep the code straight in our own minds and for our clients — but I can’t help but think I’ll be subconsciously affected by the knowledge that every .newslist li .summary might shaving precious milliseconds off our load time.

One of the things that’s been part of White Whale canon for some time is writing CSS declarations in a single-line format, with indents for parent-child relationships. From a current project:

#events { float:left; width:200px; padding:20px; background:#444 url(/images/background_events.png) repeat-x center top; color:#fff; }
    #events h3 { margin-bottom:0.5em; }
    #events .date { font-weight:bold; }

It took a bit of time to get used to at first (the practice comes to White Whale from frequent White Whale collaborator Jesse) but, since then, scanning long bits of code written the old way feels clunky.

I recently skimmed an article that briefly mentioned this coding style with the caveat that it “might produce messy results if you define more than 3 attributes for a given selector.” And we’ve had clients who objected on similar grounds. But I actually find that the opposite is true: longer lists of attributes actually hurt scannability more in the conventional style. The list of selectors is where hierarchy matters and where the cascade happens, and has orders-of-magnitude more elements than your average attributes-per-selector. Single-line declarations is may feel cluttered for those four or five attributes, but the organizational structure and lookup-speed benefits pay off where it really counts.