Eric Meyer: ‘The One True Layout’

Liveblogging a session at Iceweb 2006 (Iceweb2006; Iceweb)

In late 2005, Alex Robinson published “In Search of the One True Layout.” There’s a whole bunch of things that fall out of what he did that I don’t think even he understood. (Makes joke about Icelandic word for “layout.”)

One of the main tools for doing layout in CSS is the float. In the early days of Netscape 1.0 (which many in the audience, by show of hands, remember), there were no tables, or in any browser save for privately-developed browsers on Dave Raggett’s computer. There was no font tag, so in some ways things were better back then. There was no way to align images in content. Netscape 1.1 added tables, font, basefont, align for images.

Wow, we have this ability to stick an image to the side and have text go around it. Amazing! At the university I worked at, we spent all this time going “What will we do with this incredible new power? Why would we ever need anything else?” And this is all that floats were ever supposed to do – take something small and contained, like an image or a sidenote, and put it to the side. Never meant to be a layout tool at all. Of course, at the time they were not used as a layout tool, because there was no such thing as CSS. But we had tables, and we had David Siegel, who wrote Creating Killer Web Sites, and for five years we had sites that basically killed the Web.

If we’re not going to use tables for layout, what are we going to use? Floats were pretty much it. You could float pretty much anything; you could float a div. You could use divs to create columns. We used floats instead of positioning for one reason and one reason alone: With float came clear. You could clear the footer below all the columns that came before it. Now, it is arguable that this is no less of an abuse of a Web technology than using tables for layout. Floats were only ever meant to push things to the side so you could float content around it.

There is one advantage here. With floats or any CSS-based layout, you’re freed from worrying about how your content is ordered, for the most part. With floats, you can, if you work at it, put the content in the order of main content first, then the other stuff second and third. Floats have some source-order dependencies, so some people started adding divs. It was still better than tables, but it seemed kind of… dirty.

That’s how things were from 2000 till the end of last year, when Alex Robinson published his article, where he introduced “Any-Order Columns.” The key here is it requires no extra markup, and it only uses CSS1 properties to do it – only published nine years after CSS was finalized. As far as I know, nobody thought about it before him – or if they did, they didn’t document it, so they don’t get the credit. (He proofed the article and had to read it twice before he believed it.)

(Explains any-order columns.)

“Why didn’t I think of that?” was kind of my reaction. However, there’s one little sort of fly in the ointment here: This still uses floats for layout. From a design point of view, there’s still a problem. Column heights are not equal. Floats are only as tall as the content they contain, as opposed to table cells that stretch to the entire height of the row irrespective of how much content they have. Most people would have said it was impossible to do with fluid-width designs, though Dan Cederholm’s method works with fixed-width. Except Alex did it – in the same article. This is the part where I kind of start to hate him. And it uses just a bit of CSS2, which is only 7½ years after CSS2 was developed.

(Explains the method, which uses a very large bottom padding, an equal negative bottom margin, and overflow: hidden. Use a value less than 2³²–1, like 32,767.)

I should also acknowledge Alex’s dogged persistence in hacking through all the browser bugs. I don’t think I would have had that kind of patience.

There comes a point where I want to say: If this is the One True Layout, do I really want to be right? Because this is a lot of code (with browser hacks) that a three-cell table could easily handle. If you had a URL that targeted a named anchor, the item with that anchor would be pushed to the top of the column. That’s arguably what CSS says should happen, even though it’s plainly crazy. Alex came up with a fix for it with a container around the target that is absolutely positioned.

(Provides typically impossibly corny “analogy” to Lost in Space, which he had to explain to an audience that, perhaps to his surprise, was not composed of Americans.) David Baron says: If you bend CSS behaviours this far, you are making it harder to implement browsers, confine the possible growth of CSS (because if people depend on obscure float properties, those can never be changed), and reduce the pressure to improve CSS. Hixie counters that if browsers consistently implement CSS, what’s the problem? That’s kind of what we wanted all along. Why are we complaining now that they have implemented it consistently?

There’s a hard way and an easy way to do things, and, given the choice, most people will choose the hard way. Are we choosing an ungainly contraption to get this done? No, because there is no easy way to do it in CSS. But in Web design, there is an easy way; they’re called tables (unless you want your columns in a different presentation order from the document source). So until we have something better than either tables or complicated CSS constructions, there you have it.

Can CSS fix the problem? Yes… eventually (via CSS Advanced Layout Module).

So where do we stand now? Personally, I feel that the any-order columns solution is pretty robust. It seems to work in all recent browsers. If you keep your units consistent, any-order columns are pretty easy to do. Equal-height columns to me seem a lot more fragile, probably because there are so many hacks piled on top of it. My gut tells me that this is pushing things a little bit too far, but everybody has a different gut.

I think the reason why this sort of thing should be encouraged is to keep people experimenting with CSS. This just shows you how much depth there is to CSS – how, in some ways, little we understand it. Nine years after CSS1 had come out, nobody had looked at it in quite the right way before. We kind of don’t know what we can do with it, in a way. Some would describe that as a bug; I think of it as a feature, because I really like a simple system with complex repercussions that come out of them.

CSS does have quite a ways to go in certain areas. It’s great if you want to colour text, as long as you want one colour; it’s lovely if you want to set margins. But if you want to do advanced layouts with variations in height and width, it’s not so great for that. But it should help people provide layout to the Advanced Layout Group that is working on the Advanced Layout Module. If you unleash a technique on people, you get way more examples than if you sit people down in one room. Eric Raymond: “Many eyes make bugs shallow.” In this case, many designers bring design problems to the surface.

I do harbour this secret optimistic hope that this will actually kick browser makers into doing the advanced layout sooner. If David Baron really wants us to stop using equal-height columns, OK, start working on the advanced-layout stuff. (Same for Microsoft.) Web design is still young, right? It’s still growing and it’s maturing and it’s expanding outward in ways we might not have imagined. If we knew everything we could do with Web layout, it would be kind of boring, wouldn’t it? I like the idea that I can still be surprised by the tools I work with. Even at a code level, that to me is really interesting.

So… there you go. I came here not to give you answers [or present substantial new work], but to give you the ability to come up with your own answers. Equal-height columns work great if you don’t have named anchors. I try not to use named anchors; Jakob Nielsen said they were bad, so there you go.

1. (Question from woman.) Why are tables so evil? That was a really bad paraphrasing. The big one – and I don’t want to get too far into this, because Joe will come up here and beat me senseless – is that tables for layout can be very inaccessible. Not always, but the people who use them tend to make them that way. (Buzzing alarm goes off.) Apparently I’ve just given the wrong answer. I didn’t know Joe had a buzzer back there. Molly has a recording of a speech browser reading a table-based layout. It announces the start of the table, how many pixels wide it is, and how many cells there are. With nested tables, it takes like a minute before you hit the content. Table layouts don’t always have to be like that, but they usually are.

   99.999% of the time, if you have more markup than content, that’s just wrong. That to me is the reason why I don’t like to use tables. A simple three-cell table will do what equal-height columns will do quite easily, if you don’t care that they’re in one-two-three order.

2. (Question from man.) Aligning boxes vertically. Yes, that was the part I didn’t cover. In the same article, (Alex fixed that, too). Maybe with baseline alignment.

3. (Question from man about left/right alignment.)