BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Google Is Going to Make Pointer Events the Main Event Type in Chrome after All

Google Is Going to Make Pointer Events the Main Event Type in Chrome after All

This item in japanese

Lire ce contenu en français

Bookmarks

Google is going to make Pointer Events the main event type in Chrome, joining ranks with Microsoft, Firefox and leaving out Apple.

Rick Byers, lead of the Chrome and Blink input team, announced last year that Blink/Chrome was not going to implement Pointer Events (PE) in spite of Google’s involvement in the respective working group for a couple of years. Byers mentioned a number of reasons including Apple’s opposition to PE which would hamper its adoption, a performance issue of about 2% of the standard 16 ms frame, and the inability to handle events while scrolling. Google even entrusted the PE polyfill library they had to the jQuery Foundation.

But after receiving 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,” Byers announced recently their intent to bring back PE to Chrome and implement them firstly behind a flag. A Chromium issue has been opened and the Chromium Dashboard shows works has commenced on PE. Also, Byers discussed with Microsoft PE team to support some changes in the API to deal with the performance issue noted.

We interviewed Byers to find out more about this move.

InfoQ: How do you intend to make this work on a device that supports both types of events? Are you going to convert all TE into PE as this doc suggests?

RB: If we ship PE support, then Pointer Events would be the primary event type.  If a pointer event goes unhandled then it may fire a touch and/or mouse event.  Luckily we've learned a lot about a model like this through IE's efforts to be more compatible with the existing mobile web (by supporting touch events).  I believe the IE engineers have made good design choices here and for the most part we probably just want to capture their design in a specification somewhere and implement it in Chrome (of course it's possible we may want to make some changes once we really get into the details).

InfoQ: Jacob Rossi of Microsoft expressed his willingness to work with you on fixing any issue you might have with PE, but the PE Specs have reached the final Recommendation status at W3C, and as far as I understand only minor edits can now be done. How are you going to handle this?

RB: Work was already just beginning on a new version of the PE spec to address some of the outstanding feedback.  This is just adding one more (admittedly bigger) thing to the work to be done for the next version of the PE spec.  Ensuring the changes are sufficiently compatible with existing code on the web will be the big challenge, but I'm confident that we'll figure something out that strikes a reasonable pragmatic trade-off between compatibility and addressing our outstanding concerns.

InfoQ: Please explain why the "uncaptured-by-default model for touch input places a performance burden on the engine"?

RB: The difference is in what DOM node receives the 'move' events.  With touch, the target of the touch-move is always the element that received the touch-start (this is "implicit capture").  With mouse and (by default) pointer events, the target is always the element that is currently under the pointer.  This means that on every movement, a browser needs to do a "hit test" to figure out what is currently under the pointer.  Due to the complexity of CSS layout, hit testing is a complex process whose performance is sometimes hard to predict.  When responding to touch movement events the browser and application have 16ms per event to ensure a smooth 60fps experience, and reducing the work done during this "frame budget" is one of our top performance challenges as a browser engine.  Hit testing, even (in simple cases) when it uses up only ~2% of this frame budget is a non-trivial cost that we don't think the platform should have to pay unless the developer explicitly opts in to wanting the "uncaptured" behavior.  

A lot of the web is now designed to be "touch first" as developers have recognized that a great mobile UX is essential for user engagement.  I feel any new input API should take that reality into account and be designed to prioritize modern direct-manipulation (captured) style of user interaction.

Google intends to implement PE in Chrome on all supported platforms, including Android and WebView. PE is also implemented in Spartan/IE 10, in Firefox behind a flag, jQuery and Dojo. Apple is the only major browser maker that have expressed and not changed their opposition to PE.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT