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.
On Google Chrome and other browsers
Tim Bray wrote up the browsers he uses on a daily basis. Impressively, he uses Google Chrome, Firefox, and Safari consistently.
These days, I’m using Google Chrome for most things and Firefox for Web development. I’m hooked on Firebug and I like doing development in a browser that’s sequestered from the browser I’m using for email and standard Web surfing. Unfortunately, Firefox loses the basic speed test to Google Chrome, so I can’t use it for day to day browsing. If I were going to put up with a slower browser, I’d stick with Safari because it is a better behaved OS X application.
Like Majd Taby, I have various nits to pick with Google Chrome, but I’m using it for most everything these days. In the end, speed is the key. It renders Web pages very, very quickly. My biggest problem with it is that Google Chrome hangs a bit when you click on a link and then click on a different link on the same page in hopes of hijacking your original request and going somewhere else.
Until recently, I was using Safari for my day to day browsing. I love it as an application, but the speed difference with Google Chrome is noticeable enough to lure me away. I do still use Safari in a standalone Fluid app to read my work email (a Google Apps account) in its own application window with an unread email indicator in the dock.
It wouldn’t surprise me if Safari took another big leap forward soon and I went back to it. For whatever reason, I’ve found Firefox to be consistently uncompetitive with Google Chrome or Safari for a long time, but I’d be happy to use it for everything if they can catch up with the WebKit-based browsers.
Whenever I look at software markets with healthy competition, like the browser market, or the market for smart phone platforms, or the market for Web application platforms, I can’t help but think about the opportunity cost of the Microsoft desktop computing monopoly in the nineties. How much better would word processors and spreadsheets be had Microsoft had a real competitor for Office? How much better would desktop operating systems be had they faced real competition in that market?