Will 2008 prove the year the web grew up?

After the turbulence of the browser wars and the dot-com crash, the emergence this year of open development standards hints at a new-found maturity, argues Bruce Lawson
Written by Bruce Lawson, Contributor

If the tit-for-tat tantrums of the Microsoft-Netscape browser wars were the web's pimply adolescence, then the dot-com bust of 2000 was its traumatic entry into adulthood. Perhaps 2008 will turn out to be the year the web grew up, says Bruce Lawson.

Part of the web's coming of age has to be the publication in January 2008 of the first working draft of the World Wide Web Consortium's (W3C's) HTML 5 specification.

After three years of guerrilla spec development outside the W3C by the Web Hypertext Application Technology Working Group (WhatWG), led by Apple, Mozilla and Opera, the W3C reversed its previous decision to freeze HTML at 2002's HTML 4.01.

The W3C had originally declared that the future lay in XML, but changed its mind and decided to evolve HTML using the WhatWG spec as the basis.

The HTML 5 specification is still in development, and it's far from perfect. I'll come back to that in a later column. Some of its imperfections are due to two deliberate design decisions.

The first decision is that HTML 5 should reflect what people actually do with their websites, so the spec has to be practical, rather than theoretical. A philosophically pure document defining elements no-one wants to use is certain to fail.

The second decision is that HTML 5 should be compatible with existing browsers as far as possible, while simultaneously ensuring the language takes account of emerging trends so that it's future-proof.

That future-proofing is vital to ensure the language can stave off competition from proprietary platforms such as Microsoft's Silverlight and Adobe's Flash.

Open standards
If the web is to be the open, free and democratic environment that Tim Berners-Lee envisaged — and I believe it absolutely must remain so — then web developers need open standards, such as HTML 5, scalable vector graphics (SVG) and cascading style sheets (CSS), that include such features as proper typography, fast dynamic graphics capability, offline storage, and easy inclusion of audio and video.

All these features are already commonplace in Web 2.0, but require plug-ins, hackery or over-complicated code because, like a beloved great uncle, HTML 4 is ready for retirement and unable to deal with the complexities of the modern web.

It has been clear, since the Ajax revolution, that the web will become increasingly dynamic, requiring more and more manipulation of a browser's document object model (DOM) with JavaScript to dynamically insert, remove or modify elements without a trip back to the server.

The W3C acknowledges this, and recently published a specification called the Web Accessibility Initiative Accessible Rich Internet Applications (WAI-Aria) roadmap, which adds attributes to HTML 4 that make Ajax interactions accessible to disabled people using screen-readers or in-car web browsers that provide voice, rather than screen, output.

All the non-Microsoft browser manufacturers also acknowledge this trend, and are working on ever-faster JavaScript engines to render the Ajax-powered web.

To work successfully across the increasing range of browsers, operating systems and devices that people use to browse the web, the scripts require a stable, predictable DOM.

In the web's infancy, browsers were very forgiving of non-standard or invalid HTML — and that laxity meant it was possible for anyone to view source, cut and paste, and publish a site, powering the incredible growth of the web. But, faced with incorrect code, each browser constructs different DOMs.

Something as simple as '<b>Hello<i>World.</b>Goodbye</i>' produces incompatible DOMs, due to the incorrect nesting of the <b> and <i> elements, for example.

Defining error-handling
HTML 5 attempts to remedy this situation by defining error-handling — how browsers should deal with invalid markup so that they produce identical DOMs for the JavaScript to manipulate.

That's fine looking forward, but older browsers, such as Internet Explorer 6 and 7, are going to be with us for a long, long time, and people using them have a right to use our sites, so it's important developers make sites compatible by making sure they deliver an interoperable DOM. They need to ensure the code they write is valid and follows W3C standards.

The web is becoming ubiquitous. As a platform, it empowers individuals, connects businesses and is a retail platform generating billions of pounds a year. Such an important business tool needs to be developed by professionals, and one of the ways to differentiate between professional and amateur practitioners is their adherence to web standards.

The grassroots lobbying group, the Web Standards Project — disclosure: I'm a Web Standards Project taskforce member — has had great success in persuading manufacturers of browsers and authoring tools, such as Dreamweaver, to follow the standards. That was easy. They are relatively few in number and simple to find and then pester. The challenge now is to persuade developers to read up on HTML 5, WAI-Aria, SVG and CSS and to use them in their own work.

So, as we count down to the new year, why not make it your resolution to use the open web standards and ensure your web pages validate? This year, the web grew up. Did your coding methods?

Bruce Lawson works as an open-web-standards evangelist for Opera. He's been involved in standards and accessibility since 2002. The views expressed in this column are his own.

Editorial standards