Epicycles: are complex css layouts the new nested tables?
(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.
Pretentious introduction
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 table.
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 table?
“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.
37 Responses to “ Epicycles: are complex css layouts the new nested tables? ”
CSS as it exists today isn’t up to the job in a way most designers would like it to be. An awful lot of what it does and achieves is brilliant, but it’s got a way to go yet to satisfy ‘the creative’ designer.
I often think, while using CSS, that it feels like a tool created by coders, for designers… and that the designers were too often not asked about the sort of things they’d like to be able to do from a design standpoint. It’s a very basic design principle that we would want equal height columns, and yet we have to do coding backflips to achieve the intended effect. It’s a very basic design principle that we might want stylable form elements (without resorting to javascript replacement techniques for drop downs and the like).
CSS has done wonders, but it needs to mature further, and it needs more input from the people it’s aimed at helping, rather than the people who are doing the developing.
It feels like we haven’t got rid of layout hacks – we’ve just moved them from the HTML layer to the CSS layer. We croon about how clean and semantic the HTML is, hoping the visitor doesn’t wander over to look at the CSS.
I’ve used the negative margins since Dave Shea covered the technique on mezzoblue. But its a b***h to style from scratch.
Perhaps we need CSS Patterns, like programming design patterns. Synthesise the logic into repeatable units. (Starting with a standard approach for layering stylesheets – based on CSS specificity).
Along with CSS based constants/variables, I think an expression language is also needed.
Thank you for saying this out loud.
“wouldn’t that be so much easier in a one-row, three-column table?”
Yes, it would. That’s what display:table and display:table-cell are for – the niceties of table rendering without the semantic pollution of the table element for layout.
Usual problems apply of course, but hopefully this is the route that we can migrate to from faux columns in the future.
I see what you’re saying, but that seems an approach that takes CSS down the road of a proper programming language rather than a declarative styling language.
Incidentally, the ‘table-row’ div in Roger’s example (which I hadn’t seen before) seems unnecessary, or at least it works in Firefox if you take it out 🙂 What the specs have to say about that I don’t know.
Oh yeah, and I probably should have clarified in my original post that ‘the usual problems’ were IE retreating back with the dunce’s cap to its corner.
I actually believe that the future of the web is going to be programming languages instead of static html and css. Most sites are already using some sort of programming language to generate the html and in some cases even the css. Why not simply express a page as a program and send that to the browser.
I aknowledge that at this time the number of problems this cause are far outweigh the benefits.
CSS positioning is still young, so I find it only natural for it to be immature. We couldn’t have created something perfect from the very start. Based upon our needs, CSS will evolve and supply solutions to all of the problems we encounter in the process of webpage development.
My wishlist would be:
* constants — very useful for colors used repeatedly throughout the file. Would make for an excellent styleswitcher, as you could keep the colors in a separate CSS file.
* some expressions — comes in handy when you code liquid layouts and need the columns to be 70% and 30% respectively, but you also need some padding. Then you could simply write: width: expr(70% – 20px) instead of having to insert nested divs.
* of course, the equal colums issue and, generally, some stronger layout methods.
@ Dan: “CSS3 will introduce multi-column layouts”
GAH! Why do people keep saying this will solve our layout problems??? CSS3 multi column module is for TEXT, inline content, not block level elements!
What we are waiting for is support for display:table. DISPLAY:TABLE will solve all your problems, by emulating the display of a layout table WITHOUT the table itself.
As far as I know, the only browser that doesn’t support it is IE. It’s frustrating. If display:table had 100% support, then we wouldn’t need anything else to make our multi-column layouts work.
@ Bruce: What you are talking about is exactly what display:table does… no extra markup needed. You can insist that it be called something else, but that’s pointless. It causes the blocks to be rendered like a table.
The whole issue with table rendering is that the engine must compute the height of the columns BEFORE actually drawing them. This is why block-displays are faster than table-displays. But, if you want equal height columns, then you use table-displays.
Wow, this stuff is so over my head. I still use tables for layout and CSS for text etc. Am I dumb?
Not dumb, just a bit behind the times. Not much of an issue unless you do this professionally, in which case you need to catch up!
Something that is rarely mentioned in discussion about CSS purity is the practical considerations in the real world.
I build websites professionally (as I guess many here do), and in my company we use CSS as much as we can, we make every effort to mark everything up as cleanly and semantically as possible, we test on literally 20 different browser versions – and sometimes *it is not possible* to get the result we’re being paid for without using a table.
For us, it’s not a matter of “going back” to table-based layout – we’ve never been able to leave it completely behind. If I start telling my clients that I can’t build the cool design they’ve given me simply because I won’t use a particular HTML tag, I can kiss my business goodbye.
We’re often still required to make sites work on Mac IE 5, and that’s coming up on 6 years old now, so you can expect to see the considered use of simple tables for basic structural layout in our work until about 5 years after HTML/CSS gets an effective, easy-to-use, and universally supported replacement (which it doesn’t even have yet).
That’s the practical reality, for me anyway.
I actually used tables for two-columns layout on a simple project. I find it surprising that some developers would want to avoid tables at all cost.
This discussion is educative. I wouldn’t hack browsers to make them do what they are not (yet) capable of doing. I understand though that may suggest direction to future standards. Still, not all hack experiments are the way of the future. There are logical constraints.
It’s like the sexual revolution. Crazy people made it happen by pushing the envelope and it’s a good thing overall. Still, I wouldn’t be the one to hack girls and couples into doing “things”. Haha! Crazy parallel I make.
@Robin: i don’t think there’s necessarily that much of an issue with CSS becoming more like a programming language, as long as there are tools which obviate much of the need to actually hand-write any code. After all, PostScript is a programming language, but designers don’t necessarily have to learn to program in PostScript in order to produce useful PostScript documents . . . .
#columns { position: absolute; left: 50px; top: 50px; border: 1px solid #000 }
#columns > DIV { height: 100%; float: left; }
#columns .left { background-color: #fc4; width: 100px; }
#columns .centre { background-color: #44f; width: 300px; }
#columns .right { background-color: #f44; width: 100px; }
fixed height content
main liquid content
fixed height content
Just out of curiousity, why doesn’t this work? Simple divs with 100% height inside another div?
Personally i would use a table. I see no problems with it. But to each his own.
@ Dan Burzo:
> My wishlist would be:
>
> * constants — very useful for colors used repeatedly throughout the file. Would make for an excellent styleswitcher, as you could keep the colors in a separate CSS file.
I absolutely agree here. Whenever i code CSS, i constant feel like CSS isn’t designed properly. Font-families, for example, should all be centrally located, rather than dispersed through the stylesheet files on particular IDs. it makes me think of aspect-oriented programming: i want to define widths and margins in one place for all elements, and font families in another place.
I find it odd that an article written about an obsession of the colors of columns is on a website with no background-color.
I take exception to the idea that the faux columns approach is a hack. I use it often, and find it to be quite natural and easy to work with. Why should the BG of a col be absolutely tied to that col? With a separate BG, the designer is freed to have the col color or image be aligned/shaped as desired, including in ways that allow the col content to protrude beyond the BG.
Frankly I would keep using faux cols even if CSS3 were fully supported.
The problem with CSS of these days is that it is too much pushed to please a western web designer. I don’t understand why block elements must only expand horizontally to the full width. I almost never see real horizontally scrolling websites. This is because the design of CSS is made primarily to meet the needs of western webdesigners and there is no apparent need for such designs. It would give so much more power to CSS if the people who decide the future of it thought from global viewpoint, and maybe took more Asian folks into planning and asked for their opinions. This would give new ideas to the development of CSS and such simple “mistakes” as allowing block elements to expand only horizontally could be get rid of. Of course, I don’t know if there already are more than just mostly English speaking folks at W3C.
I haven’t read the CSS3 specification so I don’t know if there is a property for changing this setting. But I’d love to have it for sure. It is only one property after all, to allow something stretch vertically instead of stretching horizontally (and maybe have both at once).
CSS these days is just limited in (more or less) apparent places, not broken. As for other ideas I can see in the comments, such as constants, they’d be really nice to have. Maybe there would be a need for people to start planning their own CSS-like language that would fix the wanted things to push up some competition. This would question some of W3C’s authority and force them try to be better and more innovative.
I need to know how to write a website that will display a table
with 2 rows and 2 columns. I am new to html and I am having a hard time figuring this out. Would you please help me.
I’ve read through all of this…. and it has altered my original conceptions on the matter, yet does raise the following…..
1) CSS, though very powerful from a “layout” point of view, seems specifically enginered to replicate most magazines etc.
Look at the ability to position “over” other elements, the affects that can be applied using graphics as backgrounds etc.
Was it really conceived with no regard for the simplist column layouts that, for somethings, are still the prefered?
2) Hacks are more than an a “necessary evil”, they are a liability, and will come back to haunt us.
How many sites have we all built, that when these “techniques” are ignored, are going to fall apart on us?
3) Maybe those that develope the guidelines ought to be the ones that built the engines which render them?
That strikes me as the only way that the rendering will (should) follow the specifications chosen.
4) At present with have a mark-up for content, and a mark-up for styling…… we use html/xhtml/xml for the general structure and content of a site, then we utilise the CSS for the styling, presentation and prettifying of the site.
Maybe there should be a third…… an accepted mark-up for influencing these things…. much like Dom/JS….. something idiot proof, to perfom basic functions and that CANNOT be turned off, rendered differently etc.
Further, it is this part that can be ignored by certain devices. It may also include certain aspects of current CSS, such as the display:, overflow: and other behvioural CSS.
5) Retro fitting would be nice in browsers.
I recently had a minor heart attack when Mozilla 1.5 decided that the table markup in an old site was incorrect, and ignored the inline styling, and choose to render the table in default.
IS there a particular reason they decided to not only include the correct rendering based on true CSS styling of tables, rather than permitting the older methods as well?
What would happen if tomorrow one of the big league petroleum companies decided to produce only a new strain of petrol….. one that won’t run in any car over 2 years old?????
6) As a last suggestion, I cannot ask sincerely enough… (and don’t shoot me if you disagree!)
“Would those that come up wit hall these wonderful ideas for new languages, be they program, mark-up or display based, PLEASE start talking to others, and test things with people such as us”.
I cannot think of any other line of work where people are stuffed up, screwed over, delayed or in any other way buggered about by some remote group with little or no contact.
Test it first before making it of influence, please.
By the way, I love the bunny!
Merri, I had a look into this and I see what you’re saying. I was wondering if it’s just CSS or computing in general, are there programs that are geared towards presenting content in a manner whereby it is natural to scroll horizontally instead of vertically?
[…] Graphics Writing cross-browser CSS Photosensitive Epilepsy Variable fixed width layout Epicycles: are complex css layouts the new nested tables? […]
[…] e Mockup Folsom Prison Blues » Bruce On Complex CSS Layouts Bruce On Complex CSS Layouts – interesting read. […]
[…] e Mockup Folsom Prison Blues » Bruce On Complex CSS Layouts Bruce On Complex CSS Layouts – interesting read. […]
[…] exes CSS Layout die Tabellenmonster ersetzt fragt sich Bruce Lawson und irgendwie hat er Recht. Es […]
As a profesional web coder, the biggest problem with CSS is cross-broswer compatability of some of the more useful aspects of the specs. You have to stick to the lowest common denominator, which is almost always IE. Any profesionally built site has to look perfect in IE6 and not look too bad in IE5. If IE was not the market leader, then many designers would simply say they can’t be bothered to support it and it would go the way of NS4 (which even netscape.com doesn’t support)
The result is that cool features like advanced CSS selectors cannot be used. IE only stylesheets, to correct the bits that IE is being stubborn on, can help to reduce the number of hacks and tweaks needed, both to the CSS and HTML. This all adds to the complexity that we are trying to get away from.
In an ideal world, CSS and HTML would be clean, and we could code DRY (don’t repeat yourself). The high level design could be spec’ed out with minimum need to add low level clutter to deal with broswer related rendering issues.
As a suggestion for future browsers, maybe a system to programatically (ie via javascript) extend CSS. The idea being that some CSS incompatabilities or lack of support for the latest spec, could be resolved by the developer (or standard libs would be developed fixing known issues with specific broswers). The result would be that clean HTML and CSS could be written, with the messy cross-broswer hacks being fixed in one place.
Of course if everyone had the latest broswer, and all broswers actually implemented the specs, then my suggestion wouldn’t be needed. Anyway, even if my suggestion was used, it wouldn’t get backported to older broswers, and the last people to implement it would be MS, so while we still have to support broken and unfixable broswers, the solution would be of no use.
Interesting that you brought up physics — because this dilemma reminds me a little of the way physics has developed over the last 150 years. So let me indulge in my pretentious analogy. There was a time when everyone believed that light was a wave. Based on all the tests done up to that point in history, it had always behaved as though it were a wave, and so there was no reason to believe it wasn’t so (simplest explanations, like the problem with epicycles). Then someone came up with an interesting experiment that hadn’t been tried before, and that demonstrated that light behaved like a particle. That is, it wasn’t one continuous stream, but rather several individual bursts. Both sides conducted experiment after experiment and both could easily prove their own side. What has happened since? Physicists have spent those last 150 years trying to resolve the two sides. With any luck it won’t take nearly so long, but perhaps what is needed is a solution that elegantly combines tables and CSS.
I love my job (web design) and it would be so nice to come to work, design a site that looks nice in one browser – safe in the knowledge that it will look the same in all of them, sadly that is not reality.
Most of my time is spent working around not only browser incompatibilities, but also same browser – different OS ones for which you cant rely on CSS only hacks. Life’s a bitch when FF WIN looks fine, but then you look at FF MAC and FF linux and they are different.
Browser and OS sniffing is unreliable also.
What really chaps my ar*e hole though is that its the web designer that gets the wrap for it all the time, we all work damned hard to make a site work and look well.
At the end of the day I sometimes feel like web design sucks, and want to do a different job, and that is the biggest shame of all, because if all designers did this, it would be left to the dev guys to build sites and the intorweb would be thrown back to 1995.
Maybe a little late to add to the discussion. But cant W3C build a css/xhtml rendering library which browsers can use?
I don’t really see anything in the idea of another browser developed by W3C cause we already have opera which is pretty standards compliant. An external library common amongst all browser would eliminate rendering differences wouldn’t it?
Perhaps make this library as an open source project? All browsers could automatically update to the last stable version.
I too hail from the table-layout-era. I’ve gradually made the switch to css-based layout and I’m running into the same crossbrowser issues we all are. It’s time for the Browser manufacturers(NOT just Microsoft) and the W3C to push web-development to the next level and make css mature.
[…] Epicycles: Are Complex CSS Layouts the New Nested Tables? – Bruce Lawson […]
It’s a reflection of the immaturity of CSS that we need to go to such lengths to create simple 3-column layouts which render consistently across browsers. But even CSS abuse is one step closer to the true semantic web than table-based layouts. We need to test the limits of the toolset at our disposal to inform the next generation of specifications.
CSS3 will introduce multi-column layouts. Sure it will be years before we can depend on them, but that just reinforces the feeling that this is still an exciting time to be involved with the web. There’s still pioneering to be done, and the epicycle will be broken plenty of times yet.