Google's approach to standards looks like expedience and pragmatism. When the shadow DOM specification for displaying HTML 5-standard web components (like the video player) was still in development but the Blink team was close to shipping their implementation, Google's Tab Atkins pointed out "whatever API gets shipped will be frozen almost immediately".
That wasn't meant to be an ultimatum or to suggest Blink wouldn't support an agreed standard later, "just the reality that whatever syntax we choose here is likely to freeze quickly as soon as it's shipped. Even if we want to, it will be hard or impossible to change in the future." On the Blink team, "freeze" means "something that's no longer changeable (or at least is probably too difficult to change) due to compat pain."
That doesn't sound too different from Microsoft's tendency to bend over backwards to keep compatibility for enterprise customers — for decades in some cases — and the way those customers demand Microsoft let them turn off the feature in IE that blocks out-of-date versions of Active X controls like Java. The customer's always right.
But Google and Microsoft are taking very different approaches to dealing with the compatibility issues with touch on the web.
Touch isn't everything
Even Google thinks we'll need generic pointer events that can handle multiple kinds of input in five or ten years' time. But web developers who look beyond the dominance of the smartphone and tablet need to deal with multiple inputs now. As Xamarin's Nat Friedman is fond of pointing out, mobile means wearables and smart watches as well as phones. And web developers want what they build to work well on devices like Xbox One and the Amazon Fire TV — and on the millions of notebooks with trackpads and mice in the market, and on new tablets with pens like the Surface Pro 3. They want it to be easy to integrate with Cortana voice control or and Kinect gesture control even gadgets like Thalmic's Myo armband that offer muscle control.
Google's decision means that's more work for web developers, as it forces them to write multiple versions of the same code.
They'll need to support Pointer Events, and whatever Google adds to Touch Events to support different input messages, and maybe Android's Motion Events if they aren't the same as Blink's version. Even though Rossi promises that Microsoft will "continue our interoperability commitment through work in the Touch Events Community Group, including taking into consideration any marked improvements to the Touch Events API that get implemented for iOS and Android devices," that's still more for web developers to keep track of.
They'll be using feature detection (or more likely sniffing for browser user agents) to decide which of those events you get on your device, and using libraries to fill in the gaps, which means worse browser performance than a built-in browser API like Pointer Events. More complicated code doesn't just mean more work for web developers. It means more chances for code to go wrong and give you a bad user experience.
Sign up for CIO Asia eNewsletters.