HTML: The standard that failed?

Below is a response to Neil McAllister’s article about the future of the HTML standard, which starts like this:

HTML is a standard dictated by browser vendors — not an independent body.

That seems to be the message from the Web Hypertext Application Technology Working Group (WHATWG), which last week announced that it would be dropping version numbering from the HTML specification once work on HTML5 is complete. Henceforth, HTML will become a “living standard,” with the most current version of the specification being the one maintained on the group’s website. In other words, the standard is whatever WHATWG says it is this week.


Jeez… Lighten up!

You paint a gloomy picture of a cliquey oligopoly — whereas in reality, browser standardisation has never been healthier.

The Web is a better place to work right now than ever before, and those of us who were condemned to attempt cross-platform coding in the good old days remember just how bad it used to be. Even Microsoft, traditionally seen as the enemy of open standards, appears to be getting on board: with Internet Explorer 9 they have taken feedback from developers and greatly improved support for HTML5, CSS, ECMAScript and other standards.

In fact, current versions of Internet Explorer and other browsers already implement a high base level of common functionality, parsing, rendering and API support. Again, it’s worth remembering how much things have improved: for example, noone thinks twice about using div elements instead of tables, whereas only a few years ago that was virtually impossible — and noone in their right mind now would use shims and spacers, whereas that used to be only way to achieve reliable cross-platform positioning. The success of Ajax, and JavaScript-heavy sites like Google Maps, also show how far Web standardisation has progressed.

Standardisation is not just about specification documents, either. Libraries like jQuery have become de facto standards, and better coding tools, content management systems, templating toolkits and web frameworks — along with the common adoption of patterns, idioms and other best practices — have encouraged and enabled developers to produce more reliable and efficient web applications that work well for a range of browsers, devices and contexts.

HTML is a standard dictated by browser vendors — not an independent body.

Have you seen the WHATWG mailing list? The participants are an eclectic, international mix, and most of them don’t work for browser vendors. Anyone with a half-decent idea gets a hearing and, whatever the faults of the WHATWG, it’s hard to imagine an alternative that would be more democratic and open. Besides, HTML specifications *should* get input from industry, just like HTTP, DVB, or any other successful standard. As for the role of Ian Hickson, it’s worth remembering that much of the best Web technology has involved a benevolent dictator — that just seems to be the way that things get done.

implementing half-baked ideas and incomplete specifications, often in inconsistent ways. Most famously, the HTML5 committee gave up trying to specify codecs for the much-anticipated video tag when no consensus could be reached, leaving each browser vendor to support whichever video formats it saw fit.

You’re blaming the messenger for the bad news. The WHATWG is in no way responsible for the lack of consensus. Standardisation of video codecs and containers is complex and difficult, for technical, legal and other reasons, and (unfortunately) well and truly out of the control of any single standards organisation. ‘Half-baked’ is wrong, too: in reality, the HTML audio and video elements have been a huge success, incredibly liberating to those of us once condemned to dealing with plugins. These elements have already been used in a range of highly functional and innovative applications, and led to further innovations such as the Mozilla Audio API. (And, just to be pedantic, it’s the video element, not the video tag.)

Without so much as a version number to go by, it will be virtually impossible for the customer to understand — or even express — just what form of HTML that actually is. … Without a version numbering scheme for HTML, there will be no easy way to measure what has changed between the browser I’m using today and the browser I could upgrade to …

Are you saying that people care about the standards, and the versions of the standards, that their browser conforms to? This has never been the case, and seems unlikely to change. In fact, most browser users shouldn't need to know anything about web standards. Besides, browsers, just like other technologies, have never supported the whole of any standard. What interests browser users — alongside speed, reliability and all the rest — is functionality: not some bureaucratic seal of approval.

But hardest hit by this change will surely be independent Web developers, who now face the prospect of coding to a standard

Huh? Developers don’t ‘code to a standard’ — unless they don’t know what they’re doing. Decent developers code to capabilities. The language in this sentence sounds tendentious, too: ‘hardest hit by this change will surely be independent Web developers’. Bring on the violins!

But how do you set a scope of work and specify coding standards for a project when you can’t even express which version of the HTML specifications you’re coding to?

Again, this is not the way things work. Web development projects are (or should be) scoped to fit the audience: who they are, what they have, what they want and might want, their environment — and so on. Organisations can and should use coding guidelines, such as agreement on browser coverage, JavaScript libraries, patterns, idioms, coding layout and commenting styles, but I’ve never worked on a Web project that was scoped to a standard of any kind. That just wouldn’t make sense.

Overall, I don’t get the point of this article. ‘HTML5’ has been appropriated by marketeers to represent much more than the WHATWG draft specification. In a way, this is great — poor old HTML 4.01 never had such brand value! — but it just goes to show how meaningless version numbering has become.

In general, software and standard version numbering already has a checkered history, and getting rid of it for the HTML standard makes a lot of sense. Browser vendors will continue to implement parts of the standard instead of waiting for some bureaucratic finale — and to me that’s a good thing.

About Sam Dutton

I am a Developer Advocate for Google Chrome. I grew up in rural South Australia, went to university in Sydney, and have lived since 1986 in London, England. Twitter: @SW12
This entry was posted in Google, HTML, html5, Ian Hickson, standards, WHATWG. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.