Syndicated feed for Web Standards

Weblogs: Web Standards

For future growth of the Web into a pervasive medium, adhering to webstandards is a fundamental step.

Web Standards links

Atom Feed for this links blog Link blog feed

Monday, March 09, 2009

The shallowness of CSS evangelism

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.

Wednesday, February 18, 2009

The IE8 Blacklist minefield

Internet Explorer 8's compatibility blacklist is a minefield. There are serious shortcomings and issues which, if IE8 is launched in it's current state, will be as embarrassing to Microsoft as the launch of IE7 was back in 2006.

On Thursday when I wrote about IE8's Blacklist forcing standards opt-in, it seemed a simple choice of supporting one or both of IE8's standards and Compatibility rendering modes. Or if your site appears in the IE8 Compatibility Blacklist, then you needed to do nothing since you got the Compatibility Mode rendering which is exactly the same as IE7.

That is what the IE Team are saying. But in practice it's a different story.

Emulating IE7

When a blacklisted page is rendered, IE8 switches to a Compatibility View (document mode EmulateIE7). It is not IE7 proper, but meant to emulate IE7 rendering. Except it doesn't. So far this week I have witnessed two pages that render fine in IE7 proper but have rendering issues in the Compatibility View

Microsoft's argument for the Compatibility View blacklist is to give their browser users the best possible experience when they find a high-profile site that doesn't render perfectly in IE8. But the assurance that Compatibility mode functions the same as IE7 isn't holding.

Because of the rendering differences and issues, websites listed in the Compatibility blacklist will have to test in IE8's Compatibility View browser (EmulateIE7) as well as IE7. The two are not the same thing, and not 100% compatible.

Where is the real IE7?

Maybe we could add a meta tag to force the IE7 document mode instead of the EmulateIE7 document mode? Well that doesn't work either. Browser testing a high-profile page today demonstrated that the IE7 standards mode in IE8 isn't 100% compatible with the real IE7 either!

There are obvious display errors, around DOM Scripting animation and elements styled with position: relative. (position: relative is a well-known and heavily-used trigger of hasLayout, solving many IE6 and IE7 rendering issues).

At face value the IE7 rendering engine bundled with IE8 isn't functionally identical to the IE7 browser. So if triggering IE7 standards mode is how sites are going to deal with IE8, then testing in both IE7 and IE8's version of IE7 is mandatory. That is still an extra browser to support, despite the IE team's claims.

Developing with web standards

Sites built to web standards should work in Internet Explorer 8. Developers might feel that there's nothing to do, but unfortunately I believe they have more issues to deal with. The sanest path, even for them, is to opt in to IE8's standards mode.

Sites that make no declaration of their preferred rendering mode will be affected by both being added to the Compatibility Blacklist, or users having access to the "Enable Compatibility View" toggle. That means testing in IE7 and IE8 isn't sufficient, developers have to test their sites in IE8's Compatibility Mode - since that isn't rendering pages like IE7.

So opting into IE8's standards mode is practically mandatory, otherwise the developer is dealing with a minefield of rendering issues and differences.

Developing on a local network

A particularly nasty pitfall to remember is that by default, Intranets or websites running on the private range of IP addresses (e.g. 192.168.*.*) will be defaulted to IE8's compatibility mode. So you can't assume that a page running on your local network that works in IE8 will still work when it moves live.

Again in this case, the only sane approach is to opt-in to IE8 standards rendering mode.

But it's all user opt-in?

One of the arguments being used in support of the Compatibility blacklist is that it isn't enabled by default. A visitor has to select that option. This is meant to reassure us that the problem we are facing isn't such a big deal, because not all that many people will select that option.

Earlier today we installed a copy of IE8 on a fresh new VMWare image and the install offered a "Default Install" or "Custom Install" dialogue box. Neither was initially selected, and the user has to select one of those options. The Default option included subscribing to the Compatibility View, while the Custom option included a piece of text that said something along the lines of You will be able to customise every option one at a time. For typical end-user installations of IE8 they will select the easy and quick option of "Default install", and so a high number of these end-users will have Compatibility View on.

It's a choice between the lesser of two evils. Neither of them are particularly wanted. Just the Default option looks to have less hassle.

The only sane approach for a website is to trump the end-user selection and opt into one of IE8's standard rendering modes.

Blacklisting top-level domains

Compatibility blacklisting by top-level domains hurts large organisations operating on multiple subdomains. These large organisations have separate teams supporting the separate sites, each have their eccentricities and development styles. What is a good rendering mode for one subdomain may not necessarily be the best choice for another subdomain.

The compatibility view conflict can only be resolved by each subdomain explicitly opting into their preferred standards mode. Otherwise one high-profile subdomain with a rendering issue will impact all the other subdomains. Which means subdomains that are working perfectly in IE8's default rendering mode will still have to separately test in IE8's Compatibility view just in case another subdomain triggers a Compatibility Mode Blacklisting.

Looking at the evidence posted in the IE8 blog, a rendering error of the stock price charts on Google's Finance website is sufficient reason for Microsoft to blacklist google.com. Every other web presence that Google hosts on other subdomains, including Search, GMail, and News either has to explicitly opt-into a different rendering mode, or take their chances in the Compatibility Mode.

That means the only viable approach for organisations running multiple sites on subdomains is for each subdomain to explicity opt-in to their chosen IE8 standards rendering modes.

Dealing with IE8

So what's an organisation to do? Internet Explorer 8 has four different rendering modes (IE8 standards, IE7, EmulateIE7, IE8 quirks), and not a single one of them is 100% compatible with IE7.

The choice is starkly obvious; either pick one of the IE8 rendering modes and explicitly opt-in to it using a meta tag or HTTP header, or refuse point blank to support IE8.

Opting into standards

Opting into a standards rendering mode is the only viable solution. Either you pick a rendering mode that best suits your pages, or Microsoft will pick one for you.

I wasn't kidding when I said that IE8's Compatibility Blacklist essentially forces listed websites to opt into standards compliant rendering. Except today, I'm more convinced of that than ever before. Any site that could potentially be listed in the IE8 Compatibility Blacklist has no real practical choice apart from opting into a rendering mode. It's either that, or accept the Russian roulette of the supposed IE7 rendering modes in IE8.

Microsoft have made an end-run around the web standards movement. High-profile sites in a difficult quandary and there isn't an alternative solution out there that fits in with the spirit or philosophy of web standards. The only approach that makes any practical sense is for a website to explicitly opt into their chosen standards mode - the very thing we rejected one year ago.

That is a difficult pill to swallow. We are clearly not ready for IE8.

Thursday, February 12, 2009

IE8 Blacklist: forcing standards rendering opt-in

A year ago Microsoft announced (through A List Apart) that standards compliant websites would be forced to opt into a standards rendering mode in IE8. The uproar from the web standards community was loud and clear: the default should always be render in standards compliancy mode. Microsoft backed down.

So it is with considerably surprise and anger to read that Microsoft have quietly gone back to their original position. The gist of it is if you want to be sure your site renders in standards compliant mode in IE, you have to explicitly opt into it. Otherwise you risk being blacklisted and thrown into IE7 Compatibility mode.

Blacklisting domains to IE7 rendering

In a blog posting that seems to have gone unnoticed by the web standards crowd titled "Compatibility view improvements to come in IE8" by Scott Dickens, he writes:

When users install Windows 7 Beta or the next IE8 update, they get a choice about opting-in to a list of sites that should be displayed in Compatibility View. Sites are on this list based on feedback from other IE8 customers: specifically, for what high-volume sites did other users click the Compatibility View button? This list updates automatically, and helps users who aren't web-savvy have a better experience with web sites that aren't yet IE8-ready.

So if enough people click on the Compatibility View button in IE8 on pages on a website then everyone opted-in to this list will have that site rendering in IE7 Compatibility mode.

There seems to be no indication of a manual check of a site before it gets added to this blacklist, and the [t]his list updates automatically rather suggests there is no manual checking.

So if a large number of people went to A List Apart at the same time and a enough of them clicked on the Compatibility View, A List Apart's domain would be added to a blacklist. By default A List Apart would then be rendered in the IE7 Compatibility Mode regardless of whether it renders correctly or not in the Standards Mode.

Then the only way for A List Apart to be rendered in IE8's standards rendering mode is to explicitly opt into it. This is exactly what we, the web standards community, rebelled against last year.

Targetting top-level domain

What is even worse is that sites are blacklisted by top-level domain. As the IE8 blog post describes:

The data we collect from IE8 beta users is the top level domain of the website and whether the user chose Compatibility View while visiting that site.

This is insidious; organisations running multiple sites on subdomains (like Yahoo, AOL, CNN, Blogger, WordPress, Wikipedia, Ning) are exposed to a new risk: a problem with one single subdomain is sufficient to black-list all their websites into an IE7 Compatibility Mode.

That means if we invest a load of time making sure our top-priority sites are working immaculately in IE8's standard rendering mode then with enough Compatibility clicking on a site that isn't a high priority site is enough to damn all of our sites into this blacklist.

The danger here is that Microsoft don't seem to be collecting the reason behind why a visitor clicked on Compatibility View. So a couple of hundred curious people seeing if the Web Standards Project website works in IE7 Compatibility mode might be enough to stop the Web Standards Project's website from rendering perfectly in IE8. And the only way they can prevent that is to opt-in to the standards rendering mode. What message does that send to the web standards community when WaSP requires an explict opt-in to IE8 rendering?

Forcing an opt-in to standards rendering

To pre-empt this nonsense the practical course of action is to add the IE8 Compatibility view to your pages now before your sites get added to a blacklist. Exactly what Microsoft announced a year ago. They've routed around the web standards community. Again.

Two extra browsers to test in

And to spite us, last week I noticed that the IE7 Compatibility mode doesn't render pages exactly the same as Internet Explorer 7 itself.

So not only do we have to test a new browser with IE8 (which is now A-Grade according to our Graded browser support), it is looking very likely (if I can confirm the bug. Now confirmed.) we will have to test IE7 and IE7 Compatibility Mode separately.

Unreal.

Older Posts:

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