For the next 10 years, touch is all that matters, says Google. It's reversing its decision to add the Pointer Events standard to Chrome, meaning Web developers lose what could be their best chance to get a single API for handling touch, mouse, and pen input.
In January the Blink team said Pointer Events -- a technology originally built by Microsoft and now a W3C standard -- was a priority for 2014. Now it's off the agenda. Dropping support for it isn't an attack on Microsoft; Google is, as always, just being expedient and pragmatic. But its choice to stick with Apple's model for touch input development is going to cause problems for Web developers, who will now be faced with writing far more code to deal with mouse, pen and other inputs. And it highlights the drawbacks in Google's approach to performance.
[ Work smarter, not harder -- download the Developers' Survival Guide from InfoWorld for all the tips and trends programmers need to know. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
The origins and promise of Pointer Events
Just last month Microsoft announced that so many mobile Web pages are written so they only work properly on iPhones, that the Windows Phone version of IE 11 will pretend to be Safari. That includes supporting the elderly Touch Events model for scrolling, clicking, and zooming with your fingers -- a model that Apple first came up with in 2007 when the iPhone came out.
But there are problems with Touch Events: It doesn't always work well when you have a trackpad as well as a touchscreen, and it has a checkered history of standardization. When the W3C starting building a standard based on it, Apple not only declined to join in, but in 2011 it also claimed it had patents covering those touch principles. Although that's since been resolved, building a standard on top of Touch Events (which Apple wasn't involved with) didn't deal with the biggest problem -- that it only covers touch, not any of the other ways you might interact with a Web page.
In 2012, Microsoft teamed up with Mozilla to take the Pointer Events technology it built for IE10 to the W3C. This is single API for handling mouse, touch, and pen input (and maybe more) so developers would only have to write code once, instead of for all the different ways users might interact with a page.
Pointer Events was initially popular: It might hold the record for fastest-approved API. In January, the Google Chrome team who created Blink -- Google's fork of the the widely used WebKit rendering engine -- said Pointer Events was a priority for 2014. The Blink team even got as far as checking in code for a key CSS property that Pointer Events relies on, which has also been in the Firefox Nightly builds since version 28.
So why did they change their mind?
One reason is the same lazy behavior by Web developers that meant Microsoft had to add Touch Events support to Windows Phone.
"Pointer events would likely never supplant touch events on the Web (especially without support from Safari)," Google's Rick Byers explained. Plus he said Pointer Events wouldn't let you use scrolling to do other things on the page at the same time (like pulling down from the top of a Web page to refresh it).