CSS layouts vs Tables: What's the Pragmatic Choice?
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...
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
Richard said: "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."
I totally agree with the second sentence. Tables for layout is a hack. The first sentence is going to tie you into knots. Do you have a reference (like a W3 specification) that says tables are not designed for "presentational purposes".
The HTML 3.2 Recommendation is pretty damning ( http://www.w3.org/TR/REC-html32#table ) containing the statement:
"Tables: HTML 3.2 includes a widely deployed subset of the specification given in RFC 1942 and can be used to markup tabular material or for layout purposes."
That pretty much contradicts your initial statement of fact (unfortunately). However, the very next sentence is:
"Note that the latter role [using tables for layout purposes] typically causes problems when rending to speech or to text only user agents."
That inasmuch, as far as I am aware, is the only clear statement for or against tables for layout. There isn't an equally clear statement about not using tables for layout. The WCAG suggests that tables _should_ not be used, not _must_ not be used.
There's a good time-line over at: http://www.barry.pearson.name/articles/layout_tables/history.htm -- although I believe the author draws the wrong conclusions from the data.
XHTML+CSS also has some other benefits:
XHTML Basic 1.0 is the basis for WML 2.0, so any XHTML Basic compliant page is automatically viewable in a WML 2.0 capable phone.
XHTML+CSS allows different CSS sheets for screen, print, mobile-device, etc....
It is far easier to "theme" a site using CSS (just use a different CSS file) than using HTML tables.
I'm certain there are other benefits, but those are a good start, in addition to the ones that you mention.
A few points:
Tables were designed for tabular info and for column-based layouts. Check the rfc/specs thru time...
Mobile device support for html is as good (and as bad) as it is for xhtml.
Specifying a stricter format (e.g. xhtml) does not automatically make authors conform to that strictness (cf the number of xhtml advocates publishing badly formed xhtml).
The semantics of html (and xhtml1 - since it's the same) are not sufficiently rich to express information in a well-defined way i.e. /semantically/. Html only has presentational structure elements and the sooner people understand this (and that the Semantic Web has nothing to do with html4.01/xhtml1) the better.
CSS can be harder for normal people to maintain using non-specialist tools, and a good CMS makes maintenance (and "theming") easy with or without css.
Congratulations on submitting an article to DW, but please, not yet another w3c-weenie-cult ra-ra article... the web is awash with this kind of mindless, unquestioning w3c-fandom.
How about an objective, balanced article about web standards? Might even be a first... ;-)
Posted by: mattur | March 11, 2004 8:14 AM
w3c-weenie-cult?? :-) Well I'm pretty sure my DW article is not one of those.
Some responses to the points raised above:
1) Isofarro, I agree with your point that the HTML specs don't specifically preclude tables for layout. But my point (perhaps not worded quite right) was that tables are not in and of themselves a presentational device, but a structural one. Here's a quote from the HTML 4.1 spec that illuminates my point:
"HTML distinguishes structural markup such as paragraphs and quotations from rendering idioms such as margins, fonts, colors, etc. How does this distinction affect tables? From the purist's point of view, the alignment of text within table cells and the borders between cells is a rendering issue, not one of structure."
Maybe I'm a purist?
2) Andrew, good points.
3) mattur, I disagree with you that xhtml has nothing to do with the Semantic Web. It's a transition between HTML and XML, and the latter is most definitely a key part of the SemWeb.
Plus I can assure you I'm not a "mindless unquestioning W3C fan". I hope you'll find my DW article (if it gets published) is an objective summary of web design trends over the past 10 years. But then I'm sure it will provoke some discussion ;-)
Lockergnome went back not because it preferred tables but because they're not front-end specialist, and making design with web standards work requires one. I've had the same experience, and overall my feeling is that the web standards community has failed to do what all the other engineering communities have done.
I don't have to know about floating point wierdness of the Alpha chip to write a division operation in C, because some Alpha coder has already encapsulated his knowledge of that in a library. Not so for front end development, where the designers are keeping all this knowledge in their heads. All the game developers, Java people, XML fanatics, P2P specialists, etc have their own specialities, and you can take advantage of their work because it's bundled up in libraries.
If you folks, the front end specialists, don't encapsulate your knowledge in libraries, why should the rest of us take you seriously?
Lucas, you make some interesting points. As a front end guy I don't have a deep knowledge of using libraries. Dean Edwards has recently written an include that makes IE understand all the CSS that the other new browsers understand. The idea is to code to the standard and this will make IE play along.
http://dean.edwards.name/IE7/
Is this the kind of thing you are thinking of?
http://dean.edwards.name/IE7/ is very excellent, Alex, definitely the kind of thing I'm thinking of.
Another example is the tabbed headers code at http://www.kalsey.com/tools/csstabs/. That code involved a bunch of hacks by CSS wizards, plus a steady stream of patches to accommodate bug reports.