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.

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. 

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. 

Comments

Make a Comment or View Existing Comments Using Disqus

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