The Pointer Events specification, an API for Web developers to handle touch, mouse, and pen inputs in Web applications, has been published as a Recommendation by the World Wide Web Consortium. This is the Web standards group's final, mutually agreed on version of the spec.
Pointer Events was first proposed by Microsoft as an alternative to another specification, Touch Events. Touch Events was born from Apple's initial work to touch-enable Safari on the iPhone. W3C moved to standardize it without Apple's involvement, and at one point during Touch Events' development, it looked as if the spec would be covered by Apple-owned patents, with Apple unwilling to offer a royalty free grant for users of the spec. Had this situation continued, it would have precluded W3C from issuing the spec as a recommendation.
Pointer Events avoided the patent issues. It was also a more general specification; while Touch Events was designed for touch and touch alone, Pointer Events allowed developers to use similar code to handle touch, stylus/pen, and mouse inputs. Pointer Events also addressed certain problems with Touch Events, such as a 300 millisecond delay before responding to taps in order to disambiguate between single and double taps.
While the patent issue was resolved—W3C decided that Apple's patents didn't cover Touch Events anyway—work on Pointer Events continued in parallel, backed not just by Microsoft, but also by Mozilla, jQuery, and at one time, Google.
Mozilla Firefox and Internet Explorer both implement Pointer Events. In 2012 Microsoft contributed code to WebKit, the rendering engine then used by both Chrome and Safari. While Apple never enabled the code, Google offered its support, and this continued even after Google forked WebKit to produce its Blink engine. It looked as if three of the four major browsers were on track to support the specification.
But in August 2014, Google announced that it was going to drop support for Pointer Events and instead work on an extension to Touch Events to bring them up to the same level of flexibility and capability as Pointer Events already had. Google's stated rationale was that because Apple was unlikely to ever support Pointer Events, Touch Events would always be required.
Further, Google representatives argued that Apple was the dominant force in the mobile Web, and as such Google was impotent to influence developers and suggest they support Pointer Events.
Google's rationale appears not to have struck those still working on Pointer Events as particularly convincing. As jQuery developer Scott Gonzalez notes, it's not clear that Apple would be any more willing to implement Google's Touch Events extensions than it is Pointer Events.
Google also seems to be underselling its ability to influence Web development standards: IDC reports that Android shipped on some 81.5 percent of smartphones in 2014, and while some of those Android phones use old, WebKit-era versions of the operating system, many ship with new Blink-powered versions of Android. The prevalence of Blink on the Web is only going to grow, and with that kind of market share it's inevitable that Blink will become the dominant mobile browser.
Judging by the numerous comments in the Chromium bug tracker many developers seem unimpressed with Google's apparent capitulation to Apple and are frustrated that a useful API is being ignored for what seem to be poor reasons.
In the meantime, jQuery and other Pointer Events supporters recommend the use of the Pointer Events Polyfill, a JavaScript library that for the most part enables the use of Pointer Events code even in those browsers that lack native support.
Listing image by shawe_ewahs
reader comments
132