The Chromium Team Changes Mind - We Will Have Pointer Events
Written by Ian Elliot   
Tuesday, 31 March 2015

Recently we reported that both Chromium and Safari were continuing to support Apple's Touch API, despite the fact that the opposing Pointer API had been adopted as a W3C standard. Now we have the good news that the Chromium team has done a U-turn, leaving Apple to stand alone.

W3Clogo

The post "intent to Implement: Pointer Events" conveys the direction of the shift fairly clearly. What is interesting are the reasons Rick Byers gives for this change of mind.  

"Last year we announced that, despite our involvement in the Pointer Events standard, we were going to focus on incremental improvements to existing APIs (like Touch Events), rather than implement Pointer Events in Chromium.  Since then we’ve received a steady stream of feedback from web developers, framework authors, and other browser vendors indicating that they see Pointer Events as a highly valuable addition to the platform.  Since we’re committed to a web platform which evolves collaboratively through open discussion and data from real-world development, we need to take this feedback very seriously."

As already mentioned, this is good news because now we have a single API that works with a range of input devices, touch, mouse, stylus etc. which works on the three major browsers - IE, Firefox and now Chrome. This only leaves Apple's Safari as a non-standard problem for us to worry about.

The announcement sums up the situation: 

Compatibility Risk

IE: Public support (shipping since IE10)

Firefox: Public support (implemented behind a flag)

Safari: Publicly opposed  

Web developers: Mostly positive public support, including jQuery and Dojo

I seriously doubt that the Apple team is going to listen and add the Pointer Events API any time soon. 

However, the task of implementing it isn't straightforward, as Rick Byers explains. Originally the Chromium team expressed doubts about how the API could be implemented efficiently.The problem is that it needs a hit test on every pointer move, which is currently the case for mouse moves but not for touch moves. This is supposed to be too much computing for more limited hardware and Byers suggests that the API will need to be changed to make it more practical: 

"I intend to work with the PEWG (Pointer Events Working Group) to identify some (probably breaking) API changes to allow us to avoid this cost for touch by default.  This will be challenging to do without substantial compat pain, but I’m optimistic some solution can be reached to enable us to support Pointer Events without committing to this performance constraint."

It also seems that the Microsoft IE team has been helping out by explaining  its experience of implementing the API. 

chromiumicon

It is intended that Pointer Events will be implemented on all six Blink engine platforms - Windows, Mac, Linux, Chrome OS, Android, and Android WebView. 

This feels more like how standards and APIs should evolve. There are still some problems, however. The biggest is that Apple probably won't get on board any time soon and even the Blink effort will take quite some time to complete. It is also worth keeping in mind the threat of breaking changes to get the necessary performance. 

Banner


Android 15 Developer Preview Released
19/02/2024

Android 15 Developer Preview has just been released by the Android team with features including partial screen sharing and the latest version of the Privacy Sandbox.



Couchbase's Coding Assistant Goes GA
11/03/2024

Capella iQ, the AI coding assistant for developers that makes interacting with Couchbase using natural language possible, has gone from private beta to being generally available.


More News

 

raspberry pi books

 

Comments




or email your comment to: comments@i-programmer.info

 

Last Updated ( Friday, 03 April 2015 )