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


Introducing The Android Kotlin Developer Nanodegree
26/10/2020

The old Android Java Developer Nanodegree is shelved, making way for the new kid on the block - Kotlin



GitPod Adds Native GitLab Integration
15/10/2020

Users of GitLab can now make use of the Gitpod UI. GitLab is a popular DevOps tool that is used by more than 100,000 organizations. A partnership between GitLab and Gitpod means developers can make us [ ... ]


More News

 

square

 



 

Comments




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

 

Last Updated ( Friday, 03 April 2015 )