Last month the W3C, a standards body for the World Wide Web, announced that the Pointer Events specification has become a recommendation for modern web browsers. The good news is that typically, when a standard is released, developers can expect all browsers to support the feature and begin using the technology. Unfortunately, that is not always the case and at the time, Google and Apple were slowing the adoption of this standard.
Fast forward to this week, and Google has backtracked on their lukewarm reception of the "Pointer Events" standard. In a post on Google Groups titled "Intent to Implement: Pointer Events" the company said exactly that: it now intends to incorporate the standard into Chrome.
The post was met with excitement by the IE Dev Team, who has also been assisting Google in their effort to support the standard.
From the post, it appears that the Google development team backtracked on their initial decision due to feedback and a good working relationship with the Pointer Events working group.
The Pointer Events API is a low-level input API for mouse, touch and stylus introduced by IE. Pointer Events extends the MouseEvent model while offering a replacement for all uses of Mouse and Touch events. Based on the feedback we’ve received, and the productive collaboration in the Pointer Events working group, I now believe we should implement this API in Blink.
So what is this new standard and why is it important? Right now, most HTML5 content is designed for mouse input, but we all know that touch and even stylus/pen input is a growing segment for browsing the web. Up until now, handling of these non-mouse inputs has been done individually which often creates unnecessary duplication of logic and event handling overhead when adding new types of input. Thus, Pointer Events was born and it was Microsoft"s submission to the W3C that got approved.
A month ago, when the standard was approved, Google did say they would reevaluate their position, and it would seem that the way forward is to indeed support "Pointer Events".
The post also indicates that implementation will take "some time" due to "Pointer Events as currently defined requires a hit-test on every pointermove (as is the case for mousemove, but not touchmove). This imposes a performance cost on the engine which the major native mobile platforms and browsers don’t have." But Google will be working with the Pointer Events Working Group to overcome this obstacle, perhaps by "(probably breaking) API changes" to achieve it.
This means that only Apple"s Safari is standing in the way of major browser support for the W3C standard, but the outlook is good if Google is now committing to it as well.
via Google Groups | Thanks for the tip Zlip792!