Please note:While an effort has been made to make this blog comprehensible to the average slightly-tech-minded person, parts of this may fly over your head completely. Apologies in advance.
I'll admit I was kind of excited to make my way down to Loop Bar in the city for my first Web Standards Group event last night, on the topic "Everything You Know About CSS is Wrong!". I wasn't sure what to expect, but I'd heard whisperings about the subject matter, and such events are great place to exchange ideas.
Kevin Yank, a pretty famous face around SitePoint, was presenting the talk, and was great at breaking down complex ideas into simple pieces. The first part of the evening was spent looking at where layout techniques have come so far, and why... which I'll recap in case you're not familiar.
To (try to) cut a long story short: We used to use a specific piece of code, the <table> tag, to manipulate pages - nesting them to lay out everything – because there was nothing else available to give us the design control we needed. The <table> tag, however, is intended to display tabular data, not to lay out pages. It is the <div> tag (and <span>), that were added to be used as "hooks" for data in a page, to be manipulated for whatever design purposes we see fit – indeed, that's their purpose. These, however, act nothing like tables.
So along came CSS, which released us from the shackles of <table>-hood, and offered enormous amounts of control in the correct context, cutting back on effort in some ways. But due to rendering inconsistencies and other reasons, it also demanded heaps more effort in other ways and, as developers will understand, turning what should be a very straight-forward act of creating a decent cross-compatible website into a labyrinth of floats and clear and overflow and display: whatever... Fluid-width? Double the estimate...
For this reason, there are still many people out there still building sites in tables, even five years later. "Why should I change?" they say. "I'm happy! I tried CSS, but gave up after a week from banging my head against the CSS-brick-wall." And indeed, Yank argued, it makes sense, as for them <table> really is the tool for the job today. It's not buggy and unpredictable like CSS. To them, CSS feels unnatural and counter-intuitive (even though much the same can be said about tables).
And so you have huge websites like Amazon, still constructing much of their layouts using tables, as outlined below:
(Sidenote: That some parts of their content area are not made with tables is encouraging... So it's not complete fail.)
All this, Yank argued (both last night and in his book, Everything You Know About CSS Is Wrong!, written with Rachel Andrew), is set to change, with the support of CSS-table-based layouts, particularly in the next version of Internet Explorer, version 8.
(How this has come about is that Internet Explorer, which has been infamously unsupportive of web standards in the past, has recently taken to becoming more supportive of web standards. In addition, where once they had a stranglehold monopoly over the browser market share, nowadays other browsers, particularly Firefox, encroach significantly.)
Basically, those divs, which are usually the bane of your life when floated, can be manipulated with CSS to appear like a table. No more "pretend columns"; use the real thing, and even layouts with four fluid columns can be put together very easily, without any unnatural CSS hacks. They worked out the numbers, and CSS-table layouts need two-thirds of the code (potentially only half, with more complicated layouts).
In practice, both CSS methods have their drawbacks, but at the end of the day, the deal-breaker is compatibility. It's very nearly the only reason not to use this method. On this CSS reference page on the display property, you'll observe that almost all browsers support the table value - except any version of IE below 8. So in IE6 and IE7 we cannot make anything display like a table.
Yank argued last night that layouts can afford to "break" slightly - not horrendously, or inaccessibly - but enough that the website would look different; "columns" become "rows", and so on. After all, it is outdated software, and we shouldn't stop ourselves updating the web because of it, or bend over backwards for it to continue to work. The web needs to progress, and to become more accessible and correct. We follow the idea of "graceful degradation" for JavaScript, why not do the same thing for old IE?
Of course, for me the central issue in all of this is backwards compatibility. When a client signs off on a design, it's because that's how they want it. If it doesn't look like they expect it to in their browser, they'll understand that as a problem with the product we have provided, not in the software they are using to view it. In fact, same goes with most of the rest of the world.
Stats on the usual browser cross-section reveals about a third of users are using IE6, and approaching half using IE7. That's three quarters of our users, using outdated browsers that don't support CSS-tables.
We don't make portfolio or experimental sites. As a professional web studio, we can't afford to bury statements in the sites we make for clients, we wouldn't get it past them. So do I think we should jump straight on the CSS-table-layout bandwagon? Of course not – but I do think we can begin thinking about this, and planning out how we might start to work towards it. While IE6 has lingered, the move from IE7 to IE8 may not be so slow.
That's ultimately the reason we toy with the frustrating inconsistencies that CSS triggers. We use CSS because it's an investment in the future – the future of a tool that can become (and arguably already is) far more powerful than any other tool before it.