Folks were inevitably looking for clues that this might be too good to be true, and the brouhaha surrounding Microsoft’s plan for preserving backward compatibility in IE8 has provided them with ample fodder. Opera CTO Håkon Wium Lie has added his voice to the chorus in a guest post on CNet’s News.com:

Finally, it seems, Microsoft has decided to take Web standards seriously. Designers will no longer have to spend countless hours trying to get their pages to look right in Internet Explorer while adhering to standards. Unfortunately, I think that the celebration is premature. I predict that IE 8 will not pass Acid2, after all.

Håkon goes on to outline three possible scenarios to explain the seeming contradiction inherent in Microsoft’s two announcements. The first is that users will have to take explicit action in order to turn on IE8′s standards mode. The second is that web authors will have to take on this responsibility by modifying their pages in some way. Either of these would mean that IE8 would technically fail Acid2, which requires that browsers render the test page right out of the box. The third scenario would sidestep this with a hair-raisingly audacious hack, hardcoding the address of the Acid2 page so that IE8 would know that for this page, and this page only, it should default to standards compliance.

The article is a bit self-serving because Opera very publicly uses its superior adherence to web standards as a marketing tool. In a sense, they stand to lose were Microsoft to follow through with its promise to pass Acid2 (though Opera would obviously benefit in other ways). Håkon has a point, however. People want IE8 to respect standards so that web authors can use new specs with the confidence that their pages won’t break if visitors happen to be using the wrong browser. If Microsoft requires that users take any explicit action whatsoever, past experience suggests that almost none of them will, and the whole house of cards will come tumbling down.

In reality, the W3C is structured in a way that explicitly recognizes its lack of any official status whosoever. This is why W3C deliverables are called “recommendations” rather than “standards”. In contrast, the International Standardization Organization is a “network of the national standards institutes of 157 countries.” When ISO produces a standard, it carries the force of law in many countries. W3C recommendations are only as relevant as the individual vendors decide they should be.

Design and Consensus

Seen in this light, all the jostling over whizzy CSS features and new generations of JavaScript isn’t really about standards at all. It is about two things: design and consensus. Design, because we feel that we can produce better specifications if we bring together the best and brightest from a wide range of (potentially competing) organizations. Consensus, because in the mucky free-for-all that is the real-world web, no specification is worth the pixels it illuminates unless enough vendors agree to support it.

This state of affairs has made it increasingly difficult to improve the web. For one thing, vendors don’t have to implement new specs if they don’t want to, something that Microsoft (through malice or neglect) has been famously guilty of. Moreover, anyone with the requisite technical smarts and political skills can set up their own “standards” body, and whatever specs they end up producing carry no more or less weight than those of the W3C. This isn’t just a theoretical consideration. The WHATWG was set up precisely because certain browser vendors weren’t happy with the direction the W3C was taking with HTML’s evolution, and the fact that it has the support of heavyweights like Apple, Mozilla and Opera means that it has to be taken seriously.

So web standards are a chimera, and the idea that collaborative design is somehow advantageous is highly suspect as well. When did design-by-committee ever produce a superior result? I’ve participated in a few standardization efforts in my day, and never once did I manage to shake the conviction that everything would have gone more smoothly and with a far more satisfying result if the three smartest people in the room had simply kicked everyone else out and written the spec alone. So it all comes down to consensus.

Looking Backwards

The situation is further obfuscated by the perceived need to preserve compatibility with the billions of existing web pages. An article in A List Apart yesterday outlined a potential solution cooked up in secret by Microsoft and the Web Standards Project (yep, another self-proclaimed standards body). The article starts by explaining that the DOCTYPE-based solution invented as a reaction to improvements in Internet Explorer 6 (basically web pages can choose to say explicitly that they want to take advantage of new features) is no longer viable because problems fixed in IE7 cause these well-meaning documents to break. Instead, it is proposed that web authors explicitly state which version of a browser their pages render in (using a <meta> tag). The burden falls on browser vendors to ensure that any new version of their product supports the bugs, quirks and idiosyncrasies of all previous releases.

This is a valiant effort to address the Prisoner’s Dilemma that threatens to stop web innovation in its tracks. Authors don’t want to support fancy new features because many of their visitors might be using browsers that don’t support them. Vendors don’t want to implement these features if hardly anyone is going to take advantage of them. In a well-argued piece in the same issue of A List Apart, Eric Meyers suggests that the proposed tag may be the best way to get things moving again. Browser implementors will be able to fix bugs and support new or changed specs with the assurance that old web pages won’t break. The dam will break and the flame of progress will be rekindled.

Which is terrific, except that this proposal is riddled with holes. For one thing, how long can we expect vendors to continue to include code that ensures compatibility with previous versions? Already an organization like Mozilla is handicapped with respect to a newer competitor like WebKit because of the need to maintain obscure legacy code. Not to put too fine a point on it: in a few years it will be utterly impossible for a new competitor to enter the web browsing space due to the crushing burden of emulating every iteration of every rendering engine that has come before.

Moreover, this doesn’t do anything for the web author who has to decide whether to use new web specs (which is, after all, what we’re really trying to encourage). You still have to deploy two versions of a page if you want it to work with both old and newer browsers. And the “edge” workaround slipped in at the end risks invalidating the whole exercise. Why wouldn’t we expect web authors to sprinkle their pages liberally with the “edge” value rather than go through the hassle of updating them whenever new browser versions are released?

Conclusion

The truth is that no magic bullet will make our web standards woes go away. We can’t preserve compatibility with every crusty Geocities holdover while letting vendors chug forward full speed with brilliant new technological advances. We can’t ensure interoperability without condemning ourselves to slower innovation and ugly designed-by-committee specs. Something’s got to to give.

First of all, we need to lose the notion that the uninformed user (commonly known as “mom”) must be coddled in a state of blissful ignorance. It’s time to let that cherished IE6 support die. Sites will break, users will complain, and vendors (or the users’ techie friends) will reply “update your damn browser.” The same thing is happening constantly with productivity software (as people are forced to upgrade so their documents can be read by newer versions) and operating systems (Firefox 3, for example, no longer supports Mac OS X 10.3 Panther). Why should browsers be so different?

Second, we need to let browser implementors innovate at their own pace. Let’s not forget that both JavaScript and XMLHttpRequest, arguably the two most influential web “standards” of the past few years, were both implemented and rolled out as proprietary features (by Netscape and Microsoft, respectively). Browser makers should be willing to create cool new features with the conviction that, if they’re really that cool, web authors will be willing to implement two versions of their pages (or, more likely, use tools like those that are so prevalent in the Ajax world to shield themselves from the complexities of supporting multiple rendering engines). If enough authors take the plunge, other implementors will eventually jump on the bandwagon as well.

And, finally, we need to debunk the popular myth that web standards are handed down from on high, with a moral (or even legal) onus placed on all to implement them. If that were the case, why aren’t we baying for universal support of XPointer or RDF? Consensus is fantastic, but it is better achieved by producing specs that are truly innovative and useful, from the perspective of web authors and surfers alike. Test suites like the brilliant ACID2 that capture the public’s imagination are also invaluable in promoting interoperability. Let a thousand (so-called) standards bloom, and may the best spec win.