Two days ago, Google Chrome software engineer Rick Byers retweeted a photo of members of the Chrome and Microsoft browser teams having a social get together over beer, posted by Microsoft Web developer advocate Rey Bango. The photo was posted with the caption, "Proof that Microsoft and Google browser teams have love for each other." Today, Byers showed more of that love as he announced on the Chromium developer mailing list for the Blink rendering engine that the time had come to adopt Microsoft Internet Explorer's Pointer Events API in Blink.
The Pointer Events API combines all of the touch, mouse, and stylus interactions with a browser into a single set of programmable events. It has been implemented in Internet Explorer since IE 10 and has also been supported by Mozilla's Firefox team (though it is implemented currently only on the Windows 'Metro' version of the browser). But last year, despite having been part of a W3C working group on pointer events, the Chrome team had announced it would not support the unified Pointer Events API and would instead continue to develop separate APIs for hardware pointing devices and touch. Apple's Safari team has lined up squarely against the Microsoft approach, at least so far.
For developers, having a single API to rule all the pointing is extremely attractive. When the Pointer Events specification that has evolved out of the Microsoft API became a W3C Recommendation in February, jQuery UI project lead Scott Gonzalez was effusive about what it would mean for Web developers. "We love Pointer Events because they support all of the common input devices today – mouse, pen/stylus, and fingers – but they’re also designed in such a way that future devices can easily be added, and existing code will automatically support the new device," he wrote in a blog post in late February right after the W3C announcement. But without Google on board, there wasn't enough critical mass around the specification for developers to get too excited.
There have been some reasons not to go with a single API. For one, not every browser has needed to support three kinds of interaction all at the same time; there's no reason to implement mouse events in a browser that runs only on a touch device, for example. And touch events are a much different form of interaction than mouse moves and mouse clicks.
In the current implementation of Pointer Events used by Internet Explorer, as Byers noted, "Pointer Events as currently defined requires a hit-test on every pointermove"—that is, every time there's a mouse move or the user's finger moves from one place on the screen to another. "This imposes a performance cost on the engine which the major native mobile platforms and browsers don’t have," Byers said, so it may require working with others already implementing the API "to identify some (probably breaking) API changes to allow us to avoid this cost for touch by default."
Making that happen, while not significantly breaking compatibility for how pages react to touch from browser to browser, is going to be challenging—which may be why Apple's Safari team has opted to continue to have separate APIs for mouse and touch. And it's not going to be rolled into any version of the Chrome browser any time soon, as coming up with an implementation that works for Android, Android WebView, ChromeOS, Windows, Mac OS and iOS is going to take some time to pull off.
Listing image by Bin im Garten
reader comments
65