Wanted: Layout System
(This is part of the Feedback on ‘WaSP Community CSS3 Feedback 2008′ series.)
Not surprisingly, there was a lot of community feedback asking for better layout mechanisms. Actually, people were asking for any decent layout mechanism at all, which CSS has historically lacked. Floats mostly work, but they’re a hack and can be annoyingly fragile even when you ignore old-browser bugs. Positioning works in limited cases, but does not handle web-oriented layout at all well.
Why do we use floats for layout, anyway? clear. That’s pretty much the whole answer. The unique in-flow/out-of-flow nature of floats means they interact with each other and with the normal flow, which means they can be cleared, which makes them useful. Because with clear, we can float layout blocks around and then push other non-floated blocks, like footers, below the floats.
Positioning, of course, permits total layout freedom in the sense that you can put a layout block anywhere with respect to its containing block. The downfall is that absolutely positioned elements are entirely out of the normal flow, so they can’t stay out of each others’ way like floats do, and you can’t clear anything with respect to a positioned element. If there had been a position-clear or its equivalent from the outset, we’d never have bothered with floats.
(And if we can just add position-clear to CSS, that would be completely awesome. It’s been done with JavaScript and it will most likely be done again and better. It wouldn’t even be that hard to implement, at least for 99.5% of cases.)
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.
There are no equivalents in CSS. There have been various very clever attempts to replicate bits and pieces of those capabilities using CSS. What CSS does, it does very well: if you don’t need equal-height layout blocks, then no problem. If you do, it’s a massive pain. Clever techniques provide substitutes, but can’t replace what tables already do.
And please, let’s put the whole “display: table-cell will grant those abilities through CSS” to rest. Saying that is just saying “use tables for layout” with different words. Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it’s arguably worse. Using element names other than table and td to create layout tables, and then claiming it’s not using tables for layout, borders on self-deception.
Not to mention doing things that way means you’re doing your layout in a highly source-order-dependent fashion, which was one of the things about table layout we were trying to get away from in the first place.
So how do we get really powerful source-order-independent layout? I wish I knew. The Advanced Layout module has been sitting around for a while now, and even if you’re a fan of defining layout as ASCII art—which I find repels and appeals in equal measure, but that’s probably just me—there appears to be close to zero implementor interest. So how do we get those abilities in a form that implementors will, y’know, implement? I don’t know. I don’t care. We just need it, and have needed it for a good decade or so. Without it, CSS is a styling language but not a layout language. We’ve bent it into being something close to a layout language, which is nice but not really ideal.
Maybe CSS isn’t the place for this. Maybe there needs to be a new layout language that can be defined and implemented without regard to the constraints of the existing CSS syntax rules, without worrying about backwards compatibility. Maybe that way we can not only get strong layout but also arbitrary shapes, thus leaving behind the rectangular prison that’s defined the web for almost two decades.
I don’t have a concrete idea to propose here, because it’s not up to us any more. A solution was worked out over the course of several years and then found wanting by the implementors. Really, it’s up to the implementors to figure it out now. I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room and not let them out until they’ve defined something that works and they’ve all agreed to implement soonest. I might even supply food and water.
And yes, I just advocated doing this outside the W3C process. Why wouldn’t I? The process has, in the last decade, not produced anything even remotely resembling an answer to this problem. Time to try another path and see if it gets any closer to the goal.
No doubt someone’s going to spin this as “See, even noted standards zealot Eric Meyer now says CSS is flawed!”—only they’ll be wrong because this isn’t a now thing. I’ve been saying this for years in interviews, in person, and in general. Any time someone asks me what CSS is missing or should do better, the answer has always been a variant on “a strong layout system”. I’ve been saying it for at least a decade. So I’m not saying it now. I’m saying it again. And again and again and again and…
If I sound frustrated, it’s because I am, and have been for a good long while. I’m not the only one. It rankles to have CSS be, as Winston Churchill would have put it, the worst form of layout except for all the others that have been tried.
