(Last Updated on )
A discussion piece on whether sometimes css layouts are more complicated than their
table-based equivalents, and whether css as it currently stands (and its current roadmap) is up to the jobs we need it to do.
Centuries ago, astronomers believed that the world was the centre of the universe, and everything revolved around it. For most people (who didn’t live by the sea, so never saw ships’ masts disappearing over the horizon) this model worked fine. As time went on, technology like telescopes, and the need for greater predicitive accuracy from the astronomers, showed flaws in this model of the universe.
To correct those flaws, the astronomers came up with an elaborate – but incorrect – system of “epicycles” to explain certain behaviours of stars and planets, that we now know are “caused” because we all revolve around the sun. As observational technology got better and more anomalies were noted, more epicycles were added, until the theory and practice of astronomy became incredibly complex and cumbersome, simply because there was a central – but fundamentally incorrect – premise underpinning it all.
Epicycles of pre-css layouts
What’s this got to do with Web design, eh? Well …
For a long time, the only way to lay out a webpage that looked anywhere near palatable for consumers, firm’s marketeers and designers was to use tables, padded out with spacer gifs.
(In passing, I want to raise a big rousing three cheers for those who invented this technique. They took the only tools at their disposal – tables and the ability for html to resize a 1 pixel transparent gif, used them in an incredibly creative way and, in doing so, they made the Web as we know it today; a place where people can be web designers rather than people who post physics papers. Hip hip hooray!)
But then the epicycles kicked in: tables within tables within tables.. leading to markup bloat; the impenetrability of the structure if you had to edit someone else’s page without a wysiwyg editor.
This was all swept away when IE6 came on the scene. CSS could be used and, by doing so, the whole flawed premise of layout with tables was exposed.
We all evangelised css because it removed stuff from the markup that was only there for presentational reasons, changes to presentation can be made by editing just one file, so it’s easier to maintain. It’s the right way to do it.
Epicycles of css?
A few years down the line, and we’re seeing some fantastic, ingenious uses of css to layout web pages, but I wonder whether we’re not witnessing the introduction of epicycles to css.
I want to say at this point that I’m not criticising any of these elaborate layouts, or any of their creators, all of whom I have absolute respect for. This is a brain dump of an internal dialogue I’ve been having for a while. I haven’t arrived at a conclusion and would welcome discussion.
On the need for matching columns
I first started worrying about epicycles when I read about Dan Cederholm’s faux columns, with its ingenious use of a background image to simulate columns. (You’ll need to know this technique or follow the link to understand my following argument). It satisifies the deep aesthetic need for symmetry, by making columns’ backgrounds the same height, regardless of the height of the content. Even I, as a non-designer, appreciate that this is necessary in a design.
So I often use it myself, and it’ll appear here soon in a redesign that Patrick Lauke (il miglior fabbro) is helping me with. But when I use it, I feel a little uncomfortable, like I do when I enclose text in redundant
spans for image replacement.
Why? Because it just doesn’t feel like the right way to do the task; if you want to change the widths of the faux columns, you can’t only amend the values in the stylesheet – you have to go back to Photoshop and change your backing image. I acknowledge the argument that most designs depend on images just as much as they do on the stylesheet, so tweaking images is an inherent part of amending the design.
But the need to edit an image just to change the widths of the columns seems to contravene the spirit of css – particularly when (and here you’ll start spluttering and cursing) the whole layout could be much more easily achieved using a two column, single-row
Go on, admit it. Suspend the rightful arguments about the need for semantics, accessibility, eschewing the misuse of elements, and confess that you’ve thought: this would be so much easier to do, and so much easier to maintain with a simple table. You could lose the “column-spanning” background image, and it would be simpler to change the background colour of the colums with css. You could even have equal-height columns in a liquid design – so it would be more flexible than the faux columns approach.
Admit it. There ain’t no shame in that. Thinking bad thoughts isn’t the same as doing bad things.
The “Holy Grail” technique
Reading this week’s A List Apart’s article In Search of the Holy Grail got me thinking about all this again. We see a brilliantly creative technique to style a three-column page with fixed outer columns and a liquid inner columns. It’s brilliant, in modern browsers. As long as you don’t link to internal anchors and then view it in Mozilla.
The use of hacks is entirely legitimate; we have browsers with buggy implementations of css. But even if all browsers behaved according to the spec, all that negative margin trickery looks unmaintainable. It looks too inelegant, too fragile – too much like epicycles.
It’s not that this technique is at fault. It’s not that browsers are buggy. It’s the fact that we have to resort to such epicycles to get such a simple effect to work.
The addition to css of the ability to declare constants, the use those throughout the stylesheet in various rules would assist greatly in maintainability of the code.
And whisper it: wouldn’t that be so much easier in a one-row, three-column
“If you love tables so much, why don’t you use them?”
I don’t use tables because I care about semantics, and the experience of those with screenreaders (who generally hear something like “table of three colums and two rows” when a table is present in the markup, even if you’ve followed the guidelines and not added any summary or caption information for presentational tables).
I’m not advocating a return to table-based markup. At all. Ever. But the great thing about a table is that each cell “knows” the height of the other cells in the row – and, like it or not, design and aesthetics nearly always requires the neat lining up of columns and boxes – something that tables make easy.
The fact that we have to resort to such contortions to produce layouts that please the eye (in such a simple, basic way) makes me wonder if css – as we know it today – is up to the job at all.