Sliding Faux Columns
Published 20 years, 2 months pastA while back, in the summary to his article “Throwing Tables Out The Window“, Doug asserted:
There’s no longer any reason to use tables for layout, nor is there reason to maintain multiple versions of a site solely for different desktop browsers. Throw the tables out first. Trust us, they’re not needed anymore.
At the time, I remember thinking that I agreed with him for about 90% of design cases, but that there was that nagging 10% that still seemed to require tables. That would be the cases where elements have to have the same visual height, regardless of their content height, and the layout is not fixed-width. (Fixed-width cases can be easily handled using Dan Cederholm‘s Faux Columns.) The classic example is a liquid two-column layout containing a sidebar and main-content column, where the sidebar has a different background than the main content, and that background has to be as tall as the main content—and, conversely, the main content’s background has to be as tall as the sidebar’s if the sidebar is taller. There are ways to get this to happen using non-table markup, but it usually involves at least as much markup as using a simple table, and is less stable in older (NN4-era) browsers. If you go to three columns, all of which must match each other’s heights, then things get really wacky.
So I eventually got around to asking Doug about those cases, and it turned out he’d been mulling an idea similar to one I’d had but never pursued. We tossed messages back and forth, hammering away at his idea, and eventually christened it ‘Sliding Faux Columns’. Doug writes about this technique his recent post, Liquid Bleach. Here’s the basic idea in a nutshell, quoted from Doug’s post:
The trick is to create an ultra-wide background image (or two images for 3-column layouts, thus the Sliding-Doors-nature of the technique). The image is partially opaque, and partially transparent. It gets tiled vertically inside the parent container, just like Dan’s Faux Columns technique. The opaque portion of the image should match percentages of the column it helps create, so that it can be positioned with an identical background-position value. This allows the transition from opaque to transparent to become the axis point for the background’s position.
Amazingly, the technique appears to work in IE5/Win and later. IE5/Mac has some problems, and while the problems were vaguely familiar ones we never did manage to figure out how to work around them. More recent browsers, like Safari and the Gecko family, seem to handle the technique just fine.
While we were working on the concept, I threw together some test cases. They aren’t up to the usual css/edge standards, which is why you won’t find a link on the main css/edge page. I’m putting them out in public because they might be interesting to anyone who wants to play with a boiled-down version of the technique. Note that the super-wide images are only needed if you’re trying to fill a color or pattern into the background of the column(s). If you just need a vertical separator, then an image as wide as the separator (say, one pixel) is all you need. The CSS works out to be exactly the same in either case. It’s just a difference of a 3000-pixel-wide background image versus a one- or two-pixel-wide image.
The markup isn’t exactly pretty: it requires a couple of wrapper divs just to set up the column backgrounds/separators. This isn’t more markup-heavy than a table constructed to serve the same layout goals, but then it isn’t a whole lot less heavy either. Personally, I remain agnostic on which is a better approach. Bending a table to layout purposes isn’t clean, but to my eye, neither is constructing a couple of 3000-pixel background images just to get the effect a simple three-cell table can allow. You’re hacking your way around limitations in CSS either way you go.
This brings me to a question I often encounter: “Why doesn’t CSS have a grid layout capability?” It does: styled tables. That’s pretty much it, but it’s there. Until CSS gets grid-layout functionality that isn’t table-centric—the only “pure CSS” grid layout approach being to apply table-related display values to non-table elements, and boy, does that ever make a lot of sense—and that functionality is widely supported, then tables are the best grid-based layout system available in the (X)HTML+CSS space.
Before the purists warm up their flamethrowers and the CSS haters start to crow that I’ve done a Bush-style flip-flop, note that I said it’s the only grid layout system available. The designs that absolutely require such a system are that 10% I was talking about earlier. Most other designs don’t need a grid system, and so don’t need tables for layout. The current Wired News design is one, the new Chevrolet site is another, and meyerweb is still a third.
As Doug has proven with Sliding Faux Columns, it’s possible to cover a good portion of those sites that would normally need a grid system without table markup. That’s certainly interesting, and in one sense it’s quite useful in that it details the hoops through which one has to jump to make this sort of thing happen with CSS. When you get right down to it, though, I’m feeling very ambivalent about which I’d prefer to use: Sliding Faux Columns or a simple table to set up the columns. I suspect probably the latter, in my personal case. The great thing is that now we have a choice for those kinds of designs.
For the small percentage of designs that really do require a full grid system, though—and I really have seen only a few in all my years of surfing the Web—tables are your only realistic choice. I wish CSS had addressed that point in years past, so that we’d have some hope of support at present. It’s always struck me as one of the biggest missed opportunities of CSS.