Thursday, July 10th, 2008
Alex Russell has another one of his insightful posts titled Power and Authority. He talks about the core tenets and then ties it to the W3C, and who we should be “blaming” for the slow upgrade of the Web, and it requires a look in the mirror:
As a case study in putting your faith in the wrong idols, you canâ€™t do better than posts like this which â€œblame the W3Câ€ (via Molly). Blaming the W3C for not pushing the web forward is both humorously off-target and distressingly common. Iâ€™ve written about this before, but fundamentally you canâ€™t blame the W3C for failing to act because itâ€™s not the W3Câ€™s job to act. An MBA should be able to tease this out a bit more effectively â€“ any decision only requires that you have answers for five questions: why? what? how? when? who?
Answering these for pushing the web forward is straightforward, even on a simplistic level:
- Why?: itâ€™s too hard to build reasonably sophisticated interactions with current web technology
- What?: new tags, JS and DOM APIs, CSS syntax, and renderer support for all of the above. Eventually, a spec or five reflecting these new technologies.
- How?: we could try asking the W3C to do it, but they donâ€™t have any power. When theyâ€™ve been left to their own devices, the W3C has failed. Miserably. Over and over and over again. Instead, browser makers should introduce new stuff and then agree to agree on it (via the W3C or similar organizations).
- When?: introducing new features in any given browser seems doable in short-order. In the case of Open Source browsers, the answer is â€œas soon as someone decides to invest in themâ€. Competition has even spurred Microsoft to some level of action. The likely time-scale for new features over all, though, appears to be on the order of 5+ years. Thatâ€™s clearly not soon enough.
TODO: investigate ways to speed this up.
- Who?: browser makers and others in a position to affect the code that goes into the renderers we use.
Figuring out â€œhowâ€ leads you directly to â€œwhoâ€ in this case. The action we all want is the sole purview and responsibility of the browser vendors and they alone have the power to push the web forward. The â€œweb standards communityâ€ has made it clear that theyâ€™ll need the imprimatur of some authoritative body where agreement can be forced, but that hasnâ€™t kept the browser vendors from taking the initiative there, either. The big, open questions then center around how the â€œweb standards communityâ€ can make enough room for renderer vendors to try out new stuff, since thatâ€™s how we get new things. Demanding agreement on what to do before trying it out demonstrably doesnâ€™t work, so itâ€™s then imperative that there be a mechanism for the web to iterate prior to standardization. In fact, Iâ€™ll argue that this is now the biggest reason that Paul Ellis isnâ€™t getting the improvements he wants out of the web: thereâ€™s no mechanism in place by which any browser vendor can take significant risks without incurring the wrath of a swarm of WaSPs, or worse. Attempts to even begin to lay the groundwork for such a mechanism have been shot down forcefully by may folks who, like Paul, view â€œfixing the webâ€ as the W3Câ€™s job.
Standards bodies are animated only by the needs of industry to reduce costs by forcing vendors to agree on things. Like Open Source, they can act as a back-stop to the monopoly-creating power of network effects by ensuring that the price of software commodities eventually does reach zero. In this context, then, the W3Câ€™s only effective function is to drive consensus when visions for how to go forward diverge or lead down proprietary ratholes. Asking the W3C for more is the fast path to continued disappointment.
The W3C is just a sail and all sails need the wind to function. You canâ€™t blame the sail for the wind not blowing.
Posted by Dion Almaer at 10:10 am