The way web standards are developed is becoming more than usually exciting at the moment, leading to some unexpected alliances. Google's decision to stop work on the 'Pointer Events' standard for dealing with touch input on devices (originally developed by Microsoft but standardised by the W3C) from the Blink browser has led to Microsoft offering to share IE code with other browser vendors.
The offer came after two key open source frameworks (including the influential jQuery project) expressed dismay at the plan and Mozilla restated its commitment to putting Pointer Events in Firefox.
Rick Byers of the Blink team originally put the decision down to performance issues with Pointer Events, and Apple's lack of interest in the standard. Although the likelihood that Apple won't implement Pointer Events in Safari is still a key point for the Blink team, Byers has said that wouldn't stop them implementing pointer-like enhancements to Touch Events if other browsers would commit to adopting them as well. Why wasn't that same commitment from Microsoft and Mozilla enough for Google with Pointer Events?
That's where the performance argument comes in, with Byers arguing that any performance impact would drive developers away from web apps and back to native development. Being able to compete with native apps is important, but it seems odd to prioritize that over supporting web developers - although Google views Pointer Events as a "burden on web developers" that it believes its own (yet-to-be-written) API wouldn't be.
Microsoft is still plugging away and trying to persuade Google to change its mind. Most recently, Microsoft's Jacob Rossi publicly offered an unprecedented level of help from the IE team to any other browser team working on Pointer Events, up to the point of opening up some source code. "Consider this an open invitation for the Chrome, Mozilla, Opera, or Safari teams to come up to Redmond and work with us further on any remaining technical issues (or we’ll come to you if that’s easier). If it helps, we’re happy to share internal design docs, architecture diagrams, testing methodologies, and even our code (seriously!)."
Rossi says the commitment underlines "how serious we are about advocating that browsers (interoperably) implement what developers want".
Who owns web standards?
At the same time, a debate has started between the W3C and WHATWG, an alternative standards group that has been responsible for a lot of developments in HTML and CSS in recent years, about how the continually updated 'living standards' that WHATWG favors transfer to stable recommendations maintained by the W3C that developers can refer to.
Both of these disagreements reflect underlying tensions between fundamentally different approaches to how to develop web technologies. Sometimes that's creative tension that helps move the web forward; developments in browsers driven by the WHATWG are part of what persuaded Microsoft to restart work on IE after many years of little but maintenance.
Chris Wilson, who's been working on building the web platform since he helped create the original versions of Mosaic at the NCSA became chair of the W3C HTML 5 working group in 2007.
There are always natural tensions between approaches to developing open standards, he says.
"In short, the tension here is about how we continue to make the process of development of the web platform more open and more inclusive. I guess that's a good problem to have."
The web is an ever-changing platform that gets more powerful for developers to build on, but keeping up with that opportunity makes a lot of work for them.
Indeed, web developers who mistake experimental browser features still in development, for the way the web will always work on all devices, could strand us with the same kind of browser monoculture we saw with IE 6, however fast and flexibly web technologies progress. Microsoft already has the browser in Windows Phone pretending to be running on an iPhone to get some mobile sites to work properly, even though they would work on all smartphones if the developers used the W3C touch standard instead.
To avoid that kind of stagnation, it's vital that the standards process stays professional, and priorities need to be clear. The real question may be, whose priorities matter most.