Strong opinions, weakly held

Tag: HTML 5

Disparate impact in practice

Shelley Powers describes the hoops you need to go through to submit changes to the HTML5 specification:

The draft of the HTML5 spec out at the W3C is under continuous change, the formal Working Draft hasn’t been updated for some time, so we’re having to make changes on the run. To actually make these changes requires a degree of technical proficiency that has nothing to do with HTML markup. We’re told that to propose changes to the document for consideration, we need to, first of all, send our SSH2 public key into the Michael Smith, who will then set us up so that we can check out the existing documents, using CVS. We will then need to use a variety of tools, SVN, CVS, makefiles, XSLT, and so on, just to get reach a point that our concerns and suggestions are actually taken seriously.

And here’s the effect of the barriers:

HTML is a web document markup language. It is not a programming language or operating system. It is not WebKit, the Apache project, or the Linux kernel. Why it is being treated as such is because of group demographics. The recommended processes to work through issues are symptomatic of the fact that there is little or no diversity in the HTML 5 working group, virtually none in the WhatWG group. What we have is a working group run by tech geeks: not designers, not accessibility experts, graphic artists, web authors, not even web developers. Hard core, to the metal, geeks. And to a geek, the way around a problem is to throw technology at it; the way to filter input is to use technology as a barrier.

I couldn’t make up a more perfect example that bears out the point I was making in my post on disparate impact a couple of weeks ago.

HTML 5/XHTML 2 link roundup

This is a special link roundup related to the W3C killing off XHTML 2 and putting all its eggs in the HTML 5 basket. I’ve posted about this myself here.

A new way of writing a standard

I’ve been paying attention to the various goings on in the world of markup this week, and there will be lots of relevant links in the next roundup I post, but I wanted to comment on this email from Shelley Powers on Ian Hickson’s decision to give every browser maker veto power over any of the features listed in the HTML 5 specification. Powers absolutely hates this idea, but I confess that I’m intrigued.

Hickson has decided that the spec will not contain any features that browser vendors have not committed to support. This is very different from the usual standard-writing process, especially when it comes to W3C standards. In the past working groups have come up with lots of exciting new features and various rules to be obeyed and then the programmers go off and create something loosely based on that standard. The degree to which browsers are compliant with recent standards is a running joke, although things are much better now than they were a few years ago.

When asked whether each browser vendor can, by themselves, prevent a feature from being included in the HTML 5 recommendation, Hickson responds:

Not immediately, but if you had notable market share and we could not convince you to implement these new features, then yes, I’d remove them and then work with you (and everyone else) to try to come up with solutions that you would agree to.

Even if you did not have notable market share, I would work with you to understand your objections, and try to resolve them. (Naturally if your goals are substantially different than the WHATWG’s goals, then this might not go anywhere. For example, if Microsoft said that we should abandon HTML in favour of Silverlight, without making Silverlight backwards- compatible with HTML, then this would be somewhat of a non-starter, since backwards-compatibility is an underpinning of our work.)

What I find interesting about Hickson’s approach is that he makes the presumption of good faith. His process will only work if the browser vendors wish to collaborate to improve the Web experience by adding new features to HTML 5. Powers objects because she assumes bad faith on the part of vendors:

If we continue to allow one vendor/one veto to be the underlying philosophy of the HTML WG, then we might as well end working on it at this point, because I can’t see it being anything more than a race to the bottom, with each vendor looking to cripple open web development in favor of its own proprietary effort.

Worse, this process completely and totally disregards the community of users, of web developers, web designers, accessibility experts, and gives ultimate power to five companies: Google, Apple, Microsoft, Mozilla, and Opera–with Microsoft having the largest veto power. The rest of us might as well go home, because we have no say, no input, nothing of value to add to the future of the web. Not unless we crawl on bent knee to each vendor and ask them, “Please sir, I want some more.”

So here’s what I like about the Hickson philosophy. It will expose whether browser vendors want to work together to build new things everyone can benefit from, or if they want to rekindle or perpetuate the browser war. The thing is, we’ll know it earlier in the process than we would otherwise. Powers proposes a “three vendor” standard — if three vendors promise to implement a feature, it will be included. But then what happens is that the features go into the spec, those three browser vendors implement the feature, and the intransigent vendors do not? As professionals we can’t use new features anyway until they’ve been implemented. Under Hickson’s approach, the inclusion of a feature in the recommendation signals a commitment from all browser vendors to implement. We can plan ahead based on that.

If nothing else, it’s a new approach to an old problem. I’ll be curious to see what the process yields.

© 2024 rc3.org

Theme by Anders NorenUp ↑