Google is back on board with Pointer Events, but what about Apple?

Google is (finally) hoping to adopt the Pointer Events standard in Chrome, while Apple is writing custom events to handle its new force touchpad instead.
Written by Mary Branscombe, Contributor

Pointer Events is a useful standard for handling touch, mouse, keyboard, voice, pen, and any other kind of input you want. The very different handling of it by Microsoft, Apple, and Google reveals each company's approach to web standards these days.

Pointer Events is based on a spec Microsoft proposed to the W3C that briefly enjoyed the reputation of the fastest approved spec in W3C history. It was actively welcomed by Mozilla and Google - and spurned by Apple as having no advantages beyond IE compatibility.

Back in 2012, when the very first draft of the spec came out, Apple's response was to agree with Google's first concerns about the spec. Apple's Maciej Stachowiak said at the time that "combining the very different models of touch and mouse is a bad idea." He called the proposal "technically unsound" and dismissed the idea of touch in Windows as "more a neat gimmick than something that is truly compelling to users".

That's certainly the official Apple view on touch beyond phones and tablets; CEO Tim Cook once compared a notebook with a touch screen to "a car that flies and floats" or combining "a toaster and a fridge". And Apple seems to have stuck with that view of Pointer Events; at a Pointer Events meeting in August 2014 (that Apple didn't come to) it was noted that "discussion... face to face reinforces that this is still [Apple's] belief".

Google has gone back and forth on its view of Pointer Events several times as the spec has developed. As usually happens with web standards, the initial specification changed to address things people had problems with, and both Mozilla and Google seemed to be on-board.

Then after initially saying they'd make it a priority in 2014 for improving the mobile Web platform experience, Google did its first 180. At the time it said the combination of performance issues, the belief that touch was all that mattered, and the fact that Apple wouldn't implement Pointer Events meant that their idea of an extension to the Touch Events model developed by Apple (and standardised by the W3C in the teeth of patent threats from Apple) was a better approach for them - even though Apple would be just as likely to ignore that.

Mozilla disagreed with Google and said it was still working on putting Pointer Events in Firefox and Microsoft offered to share "design documents, architecture diagrams, testing methodologies and even our code" with other browser developers.

A number of web developers and several frameworks including jQuery, Cordova, and Dojo also disagreed with Google, saying they wanted browsers to support the standard rather than making them use polyfills. The jQuery foundation was so keen on Pointer Events that when the spec became a W3C Recommendation in February without Google changing its mind, it produced its own Pointer Events Polyfill.

At this point, some pointed and heated comments were made. Google briefly closed the bug about Blink not supporting Pointer Events to public comments, but within a few hours it was open again.

Web developers started asking the Blink team to support the standard, addressing Google's concern that developers wouldn't adopt Pointer Events.

And the working group members continued their discussions with the Chromium team, working through the performance problems they'd seen and pointing out the improvements to the standard.

A couple of weeks later, Google's Rick Byers announced that they'd heard the feedback "loud and clear" - and they intended to implement Pointer Events in Chromium, because many of their technical concerns were getting addressed.

Interestingly, that announcement came on the same day that Google also said "in order to do what's best for our users and the web, and not just Google Chrome" it wouldn't put the Dart VM in Chrome; instead it would focus on "compiling Dart to JavaScript". That means web developers can think about the ECMA 6 standard that's close to being ratified, instead of yet another JavaScript-like language for building web apps.

And it's just a few days after one Google developer's plaint that the web development world had ignored "beautiful fast touch interactions" that came from IE and were proposed as CSS scroll snap points turned into a lively discussion on Twitter between the IE and Chrome teams where Rick Byers confirmed "we want snap points in Blink" and the promise of a first public working draft for the spec.

The Pointer Events discussion with Google might have been messy and frustrating for web developers, but at least they were able to have the discussion - on the Chromium bug page and on Twitter. And eventually, the Blink team listened to their feedback. Many of the same web developers wanted to talk to the Safari team about Pointer Events, but there wasn't anyone from Apple talking back - or even showing any sign they were listening.

There still isn't. Instead, Apple is adding five new events to WebKit to support its new 'force click' trackpad (they're unfinished, so web developers can't actually use them yet and yes, that's five events just to handle mouse clicks).

That's the kind of input that Pointer Events would be ideal for. A specification that can handle the angle, speed, and pressure with which you use a pen can handle the amount of pressure you exert on a touchpad. But instead, web developers will be writing custom touchpad handling code alongside their Touch Events code - alongside their Pointer Events code.

Back at the Pointer Events meeting in August 2014, the jQuery Foundation expressed their frustration at Apple's failure to participate in web standards. "We need to stop letting Apple stifle the work of browser vendors and standards bodies. Too many times, we've seen browser vendors with the best intentions fall victim to Apple's reluctance to work with standards bodies and WebKit's dominance on mobile devices. We cannot let this continue to happen."

Apple isn't the only one that has commit rights in WebKit, but Apple is the only one who can decide which WebKit features and which web standards make it into Safari.

At the moment, it isn't giving web developers a good way to give their feedback about that, and it isn't paying attention to the feedback they're giving to other browser makers. Apple goes its own way and it's successful by doing that.

But that's increasingly a different path from the rest of the web, where you can see Microsoft, Google, Mozilla, and the combination of web framework foundations and web developers actively pushing standards forward.

More on Pointer Events

Editorial standards