There's a debate going on in the Web world about Lockergnome's backwards conversion from a modern CSS design to a 1997-era HTML tables design. The web design community is outraged by the decision, because it's basically a slap in the face to the Web Standards movement. Photo Matt compares table-based designs to McDonald's food and XHTML/CSS designs to healthy, fresh food. Paul Scrivens and Dave Shea both ask: what's the point in going backwards? Those that agree with Lockergnome's decision argue that tables-based designs are still the easiest and most pragmatic solution. Scoble sings the Content is King rap and Rogers Cadenhead says that "...aside from accessibility issues, no one should care how pure your markup is."
I have to agree with Photo Matt and the other designers on this - Web Standards are important and Lockergnome's decision is short-sighted. What's more I'll argue below that CSS designs are the pragmatic choice - if not in the short-term, then very definitely in the medium and long term.
The fact is HTML is a structural-based mark-up language and HTML tables are NOT designed for presentational purposes. Using tables for webpage layout is a hack, pure and simple. CSS on the other hand is specifically designed for presentation purposes. All modern browsers support CSS now, unlike browsers circa 1997, so there's little excuse not to separate structure (HTML/XHTML) and presentation (CSS).
(aside: stay tuned for my upcoming Digital Web article, which I recently submitted for review. It has a section on this very point).
But actually it's no use me moralising, I need to provide some pragmatic reasons why people should want to use XHTML/CSS...
I wrote an article back in October 2003 explaining why I'd decided to move my Radio Userland weblog from the default tables-based design to an XHTML-compliant, CSS layout. Let me briefly re-iterate some of my reasons:
- While in the short-term CSS is harder to implement than tables, in the medium-term CSS is easier to maintain. Having to fuss around with a bunch of table cells in order to re-jig a design layout, is more hassle than simply modifying a couple of lines in a CSS file.
- XHTML/CSS designs convey semantic information about the structure of your site. While you may not see many benefits of this today, think of these future benefits: Your site will be more easily rendered on mobile devices, it can be easily re-purposed to another format, it can be probed and analysed using XPath and other such technologies, it can be re-mixed and transformed with other XML content, and so on.
There are also more practical web design reasons too - e.g. CSS designs use up less bandwidth than table-based designs. All of these reasons make XHTML and CSS the pragmatic choice when viewed from a medium and long-term perspective.
RSS is actually a very good example of the value of semantically-structured web publishing (and publishing is what we do with websites too). RSS is an XML data format and the content is wrapped up in semantically-meaningful tags. I don't want to get into a debate about how semantic RSS 2.0 is compared to RSS 1.0 or Atom (that'd be like jumping out of the frypan and into the fire!). My point is that web publishing is no longer just about slapping together some HTML tags, placing it on the Web, and 'Bob's yer Uncle' that's the end of the process. When we publish to the Web using semantically rich structures and Web Standards, we make it a whole lot easier to share and re-use content. The process doesn't end when we publish - it's only just begun. That's sort of what I was getting at the other day with my There is no End User post. But I'm still working on that theory...