Weblogs: Web Standards

When promoting one thing being better than the other it is highly advisable to check the validity of your arguments before making them public. At least think about your arguments.

I get highly annoyed at the assertion that valid markup is essential for a page to be accessible. The argument lacks both substance and real world evidence, and there's a great example of the opposite: using the invalid embed element allows Flash to send updates to MSAA, which directly benefits people using screenreaders; while using the valid object element doesn't. Here I deliberately chose the invalid markup because it is more accessible.

CSS versus tables is another known permathread. It's only recently that the voice in favour of tables layout has improved it's position significantly. Unfortunately the same cannot be said about the rabid pro-CSS group. They continue to spout nonsense and hope no-one looks too deeply at the arguments, and hope enough commenters reply that it couldn't have been said better. Except there is large room for improvement, or perhaps reformulating the argument into something that is backed by real world evidence.

Matt Jurmann of Chromatic Sites published a blog post titled 13 Reasons Why CSS Is Superior to [tables]. How ironic, the CSS layout has prevented the full title from displaying! Even the abstract is horribly cropped. Even more ironic is the site tagline of web solutions that work.

Lets look at all 13 arguments and evaluate whether there's any substance. Or logic. Or common sense. Or anything substantial whatsoever.

1. Faster page loading

Apparently CSS layouts load quicker. But only if the CSS is not in an external file. Except no-one doing webstandards does this as a rule, and the benefit of visual consistency (argument 5) is thrown completely out of the window; and that has a knock-on effect on a number of follow-up arguments.

No web standards expert chooses to have the CSS embedded in the HTML page, it isn't a best practice. The only one compelling argument I've ever seen for CSS embedded in the page is when the Yahoo homepage is set as your homepage in IE6 it is actually quicker because it reduces the risk of the CSS not being cached locally. But that is merely an edge case.

In a website authored by best practices, the tables layout will be faster loading because there are less HTTP requests crossing the wire.

The CromaticSites.com site actually has eleven separate external CSS files. That's eleven additional HTTP requests before the browser has sufficient information to render or repaint the final version of the page (even if the response is just a 304 Not Modified). The performance overhead of a bigger HTML page for tables layout is minuscule in comparison.

2. Lowered hosting costs

This argument follows on from the previous discredited argument. Less bytes equals quicker download. Except again, web standards best practice uses CSS in external files, so the overhead of making an additional HTTP request dwarfs any single page size saving. This is an accepted tradeoff for site-wide consistency.

CSS can offer bandwidth savings, but this is solely down to caching. This caching is done by the browser, or intermediary caching servers. If you set proper Expires headers on your CSS, then you are likely to see a better cache-ability of your CSS. Even with proper server-set HTTP headers, the chances of caching are not as rosy as expected. The Yahoo! Exceptional Performance team has some very interesting (i.e. substantially lower than expected) statistics about caching that lead to the call of minimising HTTP requests.

But with 11 external CSS files the additional bandwidth costs of the extra HTTP requests and responses is going to consume more HTTP packets than the bigger HTML page size of tables layout.

3. Redesigns are more efficient

Apparently redesigns are easier with CSS. Unfortunately this is just theory. I've watched countless webstandards savvy bloggers redesign their blogs every once in a while. A substantial number of times this has involved changing or refactoring the markup before the styles can be applied.

With Wordpress the typical working process is to design your new site as a theme, so you have the ability to change the markup, and then author the new CSS rules. Then finally, just switch themes when you are ready to go.

In this case, the redesign efficiency of CSS isn't that immediately apparent. Tables layout can still be as efficient as CSS in this typical scenario.

The second point is that redesigns are typically site rethinks, and sites that redesign by changing the CSS alone are rare. Most especially commercial sites. An example is the Yahoo homepage redesign, they normally take 6 to 12 months, and that hardly qualifies as efficient.

4. Redesigns are less expensive

Another follow-on based on a previous discredited argument of redesigns being more efficient. A redesign is typically an overhaul of the existing site, and CSS layouts don't fare any better than their tables layout counterparts.

The theory sounds good, but in real-world practice, the argument isn't sustainable. Perhaps this only works on small trivial sites rather than the typical Alexa top-100 type sites.

5. Visual consistency maintained throughout website(s)

Matt finally gets to one of the real strengths of CSS; the ability to externalise an entire site's styles in a manner that is sharable across all pages on that site.

Yes, a great argument, except that it then contradicts all the arguments about download performance.

This advantage is also a disadvantage. Changing one style to fix a bug or improve the styling on one page can have a detrimental effect on other out-of-sight pages on the site. So a page you are not looking at can break without you immediately knowing.

Firebug only saves you on the pages you are looking at, and when your site is a couple of hundred pages it is difficult to figure out the risks involved in updating just one style rule. There's no simple way of figuring out the site-wide implications of changing one style rule. And when JavaScript is affecting what style rules apply it's an absolute nightmare to test.

Which means that developers tend to prefer adding new class names and new stylerules to try to limit the damage caused on the rest of the pages. And that results in styles that are page-specific, and thus the visual consistency of pages then degrades.

Visual consistency is a little better with CSS, but a well-planned tables layout built with real development tools has a much better chance than the typical web standards geek and their trusty text editor. Ask around how many CSS savvy web developers actually have a build and deploy process. Not many.

6. Better for SEO

Again, more nonsense with very little substance. Search engines aren't hindered by longer pages, and haven't been since the inception of the Web. Search engines index tabled layout pages as adeptly as CSS layouts, particularly with Google's preferred approach of disregarding markup semantics and heavily favouring actual text meaning.

Some search engines do stop at the first 100Kb of content, but that's regardless of whether the page is tables or CSS layout. And if you can't fit a page's content into 100Kb you have bigger issues than just tables for layout. Like Information Architecture issues.

An argument that could be considered in CSS' favour is that a semantic search engine could read more into a CSS layed out document (assuming that CSS is applied to an existing well-structured document). But this isn't what is happening with today's popular search engines. This is something that may prove beneficial in the future, but not today. But it is also a chicken and egg situation, there's not enough well-structured pages out there to make it worth relying on semantic structure, and semantic structure isn't useful to search engines today so there's no point spending too much time with them if that's the only argument for it. But that's neither here nor there, a table layout can just as easily use proper headings and markup for its content than a CSS layout; or both can be just as bad as the other.

Search engines ignore all markup by default, and whitelist certain constructs, like links, headers, bold, image elements. All of these structures are possible with both CSS and tables for layout.

Jurmann's point about rollovers is complete nonsense and has no bearing on the search engine visibility of the page.

7. Accessibility

Ah, the accessibility card. Except Jurmann picks the wrong definition of accessibility - the one about the availability or universality of a page (for example, server uptime). In this case CSS for layout doesn't do anything to preserve the uptime of a server.

Now turning to accessibility: as in making content and services perceivable, operable, understandable and robust for people with disabilities:

It is very possible to create an accessible website with tables for layout. Heck, two of the best accessibility books on the planet go into detail about how to minimise the accessibility barriers of using tables for layout. CSS can still create accessibility issues, and that still needs a watchful eye just like their counterparts.

CSS layouts are no more accessible than tables layout. Screenreaders have had to deal with layout tables since the inception of the web, and they do a fairly decent job at making them transparent to the visitor so much so that most of the time they do not realise the difference between CSS and tables layout.

All of the accessibility techniques the Chromatic piece talks about have nothing to do with CSS layouts, but of CSS styling. Font-sizing, styling of lists, these are all quite possible with tables layout too. This isn't an advantage of using CSS for layouts, it's an advantage of using CSS for styling content.

8. Competitive edge (job security)

And here is the ugly truth about CSS evangelism: the elitism. CSS layouts aren't as easy for the vast majority of people building websites. So obviously, people who can do CSS layouts, and write articles about 13 reasons why CSS layouts are better than tables, well this is the part where they assert that they, the CSS layout gods, are so much better than the typical site builder.

Job security for learning something asserted to be easy? That's an interesting contradiction. Where's the job security in knowing something that's easy? Surely the people working with tables based layouts have better job security because CSS is so much easier, and it requires more dexterity and skill to edit a tables layout?

And frankly, this dismissive 'CSS is easy' is disgusting. CSS is not easy. The learning curve is steep, and not well mapped. CSS layouts are very much stuck in the Dark Ages as alchemy was. A decent text about building reusable stable layouts with CSS is yet to appear, and that's more down to the immaturity of CSS itself. Building solid reliable layouts in CSS is a Black Art.

Learning how to use tables for layout is actually far simpler. The number of hacks and workarounds to render a reliable and stable non-trivial layout is actually far fewer and less complex than the CSS hacks and workarounds.

9. Quick website-wide updates

Another riff on the consistency across sites argument. Sure, updating one single style will affect all the pages on the site. But a proper build and deploy process also does that, so layout tables can have this feature too. No modern website with a sizable audience doesn't have an automated build and deploy process.

10. Easier for teams to maintain (and individuals)

Yet another riff on consistency across pages, and without mentioning the downside. Surely changing on thing that results in changes across thousands of pages also means those thousands of pages also need to be tested individually? This is the great risk with CSS, you can destroy a page you weren't intending on changing, and without knowing it.

CSS for site-wide styling is a double-edged sword, you can just as easily cut yourself with it. The testing burden alone is a sufficient reason not to use CSS for site-wide consistency.

And yet, site-wide CSS styling of content (as opposed to layout) can, and are, used in tables layout to style the content. The clean separation of presentation and layout means that in a tables layout site, site-wide changes to styles are less likely to trigger a degradation of a page layout because tables are so robust. So it is actually safer to use tables for layout.

Jeffrey Zeldman's original edition of Designing with Web Standards advocated a tables layout, and using CSS for the rest. CSS was deemed not to be mature enough when this book was written, and in layout terms it hasn't improved that much, and tables layout are still far more stable than CSS (for real world layouts).

11. Increased usability

Apparently the ability to have a print stylesheet means improved usability. Well well. With the typical automated build and deploy systems in use across most leading websites it is fairly trivial to create a printer friendly version of pages with very little effort or overhead. So the advantages of a print stylesheet are negligible.

The continual assertion that CSS downloads faster makes another appearance. Yawn.

12. More complex layouts and designs

Another baseless and unsubstantiated assertion. It took a long time for CSS to mature enough to be able to create layouts that were straight-forward to do with tables. The canonical example of a headered and footered three column layout with the middle column fluid (the 'Holy Grail' of layouts) is still remarkably simple to do with tables, and yet a minefield of issues for CSS. The CSS equivalent requires trade-offs and compromises to get into a reliable state.

CSS is starting to get an edge in pixel-specific layouts. So grid based layouts, those much praised by designers and the print world, that is almost doable in CSS now, whereas they've been relatively straightforward with tables for well over a decade.

Layouts that require overlaying, cropping or relative positioning are obviously not straightforward with tables. And yet, considering the accessibility and usability implications of such techniques, maybe that's a positive thing for tables. Considering the number of cropping and lost content issues with the Chromatic sites website, perhaps they'd be much better off using tables for layout instead? They certainly wouldn't have had their titles and abstract cropped!

13. No spacer gifs

Tables for layout doesn't automatically mean the use of spacer gifs. Designing with Web Standards by Jeffrey Zeldman detailed how to create table layouts without needing these.

The merits of evangelism

These kool-aid induced advantages of CSS lack substance or real-world experience. As a sceptical observer who is well versed in using CSS, I find the points raised underwhelming and unconvincing.

Why am I critiquing like this? Well, I find the level of discourse about CSS layouts low. There is too much back-patting and self-congratulations going on. These CSS are better than tables articles, as they are currently published, are doing nothing to improve web standards or encourage an interest in CSS.

ESPN, Wired and the Blogger redesign were three tremendous examples of the practical benefits of CSS layouts. These sites inspired people, encouraged people to give CSS a whirl.

Eric Meyer's books on using CSS in a practical manner are also as inspiring as they were instructive. I'd recommend both "Eric Meyer on CSS" and "More Eric Meyer on CSS" for people who are curious about what CSS can do. But they don't talk too much about actual page layout. Yes, there's coverage of simple layouts, but not those sort of layouts that make up the vast majority of corporate sites.

Evangelising CSS shouldn't be about my tools being better than your tools. People working on existing sites get paid to keep sites using tables for layout up and running. It is simply not cost-efficient to not support these sites. They are not going to be completely convinced by these arguments and start tomorrow off by deleting all layout tables - that's the quickest way to not having a job, and in the current economic climate, that's not a clever move.

Tables for layout work. Their deficiencies, and workarounds, are well understood and easy to learn. For the typical corporate web developer debugging a table layout is far easier than a CSS layout. The risk of unintentionally breaking other pages on the site by fixing one issue on one page is substantially smaller than site-wide CSS.

The core argument that CSS evangelists fail to acknowledge is that companies with big sites can't afford to change the entire site in one go. There is no clean-slate approach to revamping these sites. Projects are broken up into little phases of deliverables. Sometimes there's a three month project to change a tiny part of the page measuring not more than 250 pixels by 32 pixels. Full site redevelopment is practically a non-starter.

What is worse, is when these webdevelopers see lame articles about how CSS is much better than tables for layout, they only need to see though the nonsense of one single argument to realise that these articles lack substance and real world evidence. And when measured against the harsh realities of an existing website, these arguments are ridiculous and serve only to distance developers from using CSS. And so the status quo remains.

Advice for CSS evangelists

CSS evangelists, consider the merits of your arguments thoroughly. You'll find that CSS isn't better than tables for layout; it's just different. Just a different set of trade-offs and compromises. Deepen your understanding of CSS, especially it's shortcomings, limitations and it's compromises.

Belief doesn't build websites. Toil and sweat produce websites. Belief doesn't get things working. If you only believe CSS is better than tables for layout, then perhaps you aren't the person who should be evangelising to people who have a solid track record of delivering real websites with layout tables.

Be prepared to back up every single one of your arguments. There is nothing worse than an evangelist who doesn't have the knowledge, practical experience or evidence to back up his claims.

And most importantly, understand the web as it exists today. The past and the present cannot be forgotten. The future is something we can aim for, but not at the expense of a business continuity.

Maybe these CSS evangelists need a break from the kool-aid? That would be a start. Perhaps then a rationale dialogue will be possible.

The guys behind Chromatic sites perhaps should spend less time exhorting the perceived advantages of CSS and how easy it all is and spend more time fixing the CSS issues on their own site. Some people talk the talk, but don't walk the walk.

---

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]