Epicycles: are complex css layouts the new nested tables?

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? ”

Comment by Dan

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.

Comment by Matt Wilcox

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.

Comment by Isofarro

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.

Comment by Robin

“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.

Comment by Bruce

Nice idea, Robin. I assume you mean like Roger’s example of equal height boxes with css?

But I still maintain that display:table and display:table-cell are kludges, just like html tables. What I want are equal-height divs (or any other element). I don’t want tables (which are for tabular data, and were always a hack to achieve the balanced-height divs).

This css2 you propose removes the pollution from the markup, and dumps it into the stylesheet.The table paradigm is flawed; there should be no need for “container” elements that display as table-rows (and pollute the markup, just like html tables do). It also perpetuates the idea that things are laid out in a “table”, which is an unfortunate side-effect of its nomenclature.

I simply want to be able to add this presentation effect to the elements themselves, using css. So, if I want equal height columns (like Cederholm’s faux columns), I should just be able to define each div in the normal way and add the css

div#leftcol { ....colours, background, padding etc ..
height-tied-to: div#rightcol;}
div#rightcol {height-tied-to: div#leftcol;}

For a three equal-height column layout, each is tied to the other two, so the selector could be something like:

div#middlecol {height-tied-to: #leftcol #rightcol;}

telling the browser to render them all at the height of the “tallest” column.

It occurs to me that you might want the divs to line up to the height of the shortest, and have scrolling overflow, in which case you could use something like

div#middlecol {height-tied-to: min (#leftcol #rightcol #middlecol) ;}

No epicyclical “rows”, no kludges: it’s not a table, it’s equal height columns for a pleasing layout.

As an aside, it seems odd that display:table and display:table-cell have no effect in IE, given that every graphical browser already has the algorithm to render this (although that algorithmm is currently called by html tables). (See the live versions on PPK)

Comment by Robin

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.

Comment by Robin

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.

Comment by rune

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.

Comment by Dan Burzo

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.

Comment by Christian Montoya

@ 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.

Comment by Christian Montoya

@ 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.

Comment by Luke Redpath

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!

Comment by bruce

Christopher Bentley joins the fray, also pointing out that the css display:table-cell makes equal height columns in modern browsers (not IE6) and offers a good example.

Of course, he (and the previous commenters) are correct; if IE implemented this part of the spec, it would be possible to use equal-height columns in css.

But I don’t think that the way that the css spec makes you do this is the best way, as it forces the designer to think in terms of “layout tables” (and we’ve been spending years unthinking tables).

For example, there’s the necessary-for-spec (but conceptually redundant) div that wraps the equal-height columns: <div class="column-group"> that is styled display: table; . It’s conceptually required if you’re thinking about tables, but completely spurious if you’re thinking about columns. Why should you need a wrapper, rather than style the columns themselves?

Styling columns to be of equal heights is purely presentational and should be done in css (in a similar (but much more elegant) way that I describe above). So why is the extra mark-up – extra structure required? It still doesn’t completely seperate structure and presentation.

I acknowledge, however, that I’m being way too purist/ philosophical. If IE7 could adapt its perfectly good pre-exisiting html table rendering algorithm to rendering these css display styles, we’d all be singing Hallelujah and dancing naked in the streets with joy. So I’ll shut up now!

Comment by Joel Finch

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.

Comment by Serge

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.

Comment by Alexis

@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 . . . .

Comment by Kent

#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.

Comment by caleb

@ 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.

Comment by Bruce

Kent – the example you give still only puts a background colour as deep as the content in each column; the requirement is that each colour go the full depth of the column,so each colour extends all the way down to match the length of the longest column.

Comment by Big John

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.

Comment by Merri

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.

Comment by karen

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.

Comment by bruce

Hi Karen
If your data really is a table (e.g., it’s a calendar, a timetable or some kind of spreadsheet), Jim Thatcher has a course on accessible tables.

If you’re not displaying tabular data, but were planning to use a table to lay out a page (banner here, menu here, footer here, logo here), then you don’t need a table at all, you need Cascading Style Sheets (CSS). Look at all the layouts on this Layout Gala, and they invite you to steal the code.

Best of luck!

Comment by Autocrat

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!

Comment by Matt Turner

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?

Comment by James McGuigan

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.

Comment by fragrances

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.

Comment by TomFunk

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.

Comment by Tim

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.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.