Dave wrote under the heading "Stop trying to do something 'right' and do something that works":
I'm on a web development mailing list where recently someone asked about the "3 column" web page layout. He was using tables, but wanted a "better" solution, so several posts regarding CSS layout followed. Then the following arrived:
- Stop trying to be 'right' and just do something that works.
The implication being, go back to tables; it's a simple page requiring a simple solution. I've talked about this sort of siutation before and I tend to fall into the 'right' camp. I often spend a long time implementing a 'right' solution, often more time than I should. Others I know go for the simplest solution, spending less time and less worry getting something working. It's always a trade-off.
[Via writerus drivelus]
Now this misplaced guilt about doing the 'wrong' thing - where the wrong thing is defined as 'not using pure CSS solutions to solve every problem' - has to stop. Dave seems to come down on the side of doing the right thing. I'm afraid I side more with the anonymous poster Dave quotes. Since when is 'making it work' the 'wrong' thing to do?
I'm not arguing for doing the -first- thing that works, or the -easiest- thing that works; I'm arguing that the first criterion for being right is 'does it work?'. If it don't work, it ain't right. When we're talking about a web application, of course, 'works' usually has to mean 'works in any browser, is accessible, and looks good'. So 'do something that just works' isn't an excuse for doing something that looks rubbish, or is inaccessible, or won't render in most browsers. But if you can't make something that does all this using 'pure' CSS, then pure CSS is the wrong thing to do for your application.
The web application I spend my days coding on uses as its primary layout a header, left-hand navigation bar, and footer, like this:
The layout resizes smoothly to take advantage of whatever window size your browser is, neatly frames the page content no matter how large or small that content gets, handles user-selected font-size changes, and flips neatly into a mirrored form when the body's text direction is set to 'rtl', which is an important consideration for internationalisation. The content of the page, when linearised, is in a logical order. It looks great in all browsers, and is navigable using screen reader software.
The dirty secret? We use a table to lay it out. And in spte of repeated attempts to do so, we've not found a 'pure CSS' way to achieve all of those results - there's always somwhere that we'd have to compromise, whether it's in IE 5 support, or in having the page width fill your browser window, or in RTL support. And isn't it crazy that that's the case for what amounts to the simplest, most common page layout used on the web?
So do I feel guilty about using a table? Well, I did for a while, but then I realised that actually, the page works. 'But it uses a table for layout!' you say, 'how can it be accessible?' well, yes, the WCAG says 'Do not use tables for layout unless the table makes sense when linearized' (emphasis mine) - and our table does make sense when linearised, so I sleep at night just fine thank you. The same effects can not be realised using current CSS as supported by actual browsers that exist.
I want to just reiterate the right-to-left language issue, because frankly CSS's RTL support turns out to be pretty half-baked. If you manage to accomplish a layout using CSS, you'll be doing so with heavy use of floats, margins, paddings, and absolute positions that are littered with the key words 'left' and 'right'. And browsers follow those instructions to the letter - regardless of the overall flow direction of the text in the page. In some future CSS these words may be replaced with 'before' and 'after' or variants, but right now, CSS does not automatically reflow your page for RTL language content.
In fact, we ended up writing a regex-based mirroring filter that we can pass our CSS through that rewrites our CSS, swapping lefts and rights, moving all our borders and paddings and margins to the correct side of the content. It's an ugly hack, as so many of the compromises forced upon us by the limitations of current CSS and current browser support for CSS seem to be.
I love CSS in principle, and I use it exclusively for colour, background images, text styling, and paragraph layout, at which it excels (although I am very grateful that we run our CSS through a template engine so we can centrally specify colours and reuse common chunks of markup - without it, changing colours in the application would be a nightmare of search and replace) - but the fact is, it really doesn't solve page layout issues, and that won't be changing any time soon.