Just Browsing

Is Web Standardization Obsolete?

Most people seem to labor under the misconception that web standardization is a well-regimented, orderly process with a clear set of rules. In particular, the uninitiated believe that the World Wide Web Consortium (W3C) is the anointed standards body for the web. Vendors get together, agree on some new markup or scripting language that eventually receives an official mandate. Everyone is then expected to implement it.

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.