The Chromium team announced back in August that Google is no longer working on implementing Pointer Events in Chrome in order to focus on Touch Events. Now they have given control to the Pointer Events polyfill library to jQuery which is hoping to “drive developer adoption of this unified event system” and eventually see “all browsers implement this standard natively.”
W3C has recently advanced the Pointer Events standardization process to the Proposed Recommendation stage in spite of lack of support from Apple and Google. Pointer Events was proposed by Microsoft, and while Google initially supported it and the Polymer team created an implementation library, now they lost interest due to “growing consensus at Google that Blink shouldn’t invest in Pointer events at this time. Not ruled out, but no plans to implement,” according to a discussion between representatives of the major browser manufacturers held earlier in June. Apple proposed Touch Events and they are staying with it.
Pointer Events were created by Microsoft as a generalization of the initial mouse events mechanism, enabling developers a smooth transition from desktop to mobile web development and providing the ability to deal with multiple input devices: touch, stylus, mouse, etc.. While this was “very attractive” for the Blink team two years ago, now they say it “doesn’t fit with current priorities”, which are:
- Mobile First. Pointer Events make sense for a “desktop-first perspective”, but Google considers we live in a mobile-first world. As a result, they say “touch events are here to stay” and web developers will need to learn coding for them, and Chrome will have to support them. Their desire is to “make our story on mobile clean and like existing native mobile platforms: listen only for touch.”
- Performance. Google says Pointer Events carry a “hit testing and double event dispatch burden” taking ~2.5% of frame time, unlike native mobile. Also, a “pointer move/enter/leave/over/out handler anywhere on the page would require us to hit-test, even if most code was using touch events.”
- Features. Google argues that Pointer Events do not “permit scroll-interaction effects like pull-to-refresh or drag bubbling to scroll” and they are “no longer willing to sacrifice richness for threaded scrolling.”
Life is harder for web developers if they are to support two event dispatchers, and Microsoft’s representative said they want “the web to work no matter what input device you have” and “people to register for [only] one set of events.”
Another issue to consider is that the input type can change in a session, and some websites disregard other input types if touch events are enabled which is problematic for users with multiple input devices, such as touch-enabled laptops.
Since Apple and Google pretty much control the mobile development landscape, pointer events will face an uphill battle. And Google intends to “invest in incrementally evolving Touch Events,” perhaps to make it better for handling multiple input devices.
Developers still have the option to use Pointer Events, now that jQuery will continue the development of its open source implementation. The polyfill library works on Chrome 18+, Safari 6+, IE 10, Firefox 14+, and partially on Opera 12-14. But natively, only IE supports it and Firefox via a developer flag.
