RE: options for eliminating hit-tests for touch pointermove by default

Excited to have you on board (again)! :-)

There are certainly valid use cases for implicit capture (I think UX arguments are more interesting than the perf argument, but either way). As you point out, it’s a complex topic. So I agree the best course of action is to have a discussion on a call to brainstorm a bit.  I think compat may be an issue at this point with the simplest approach you describe below, but I’m confident we can find a way to satisfy your concerns while minimizing compat impact.

I’ll be out of the office for a few weeks. But I look forward to joining this discussion when I return (I’ll be back April 6th).

-Jacob

From: rbyers@google.com [mailto:rbyers@google.com] On Behalf Of Rick Byers
Sent: Wednesday, March 25, 2015 9:10 AM
To: public-pointer-events@w3.org
Subject: options for eliminating hit-tests for touch pointermove by default

Today I announced<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ODWmcKNQl0I> my intention to work with the working group to resolve outstanding technical issues with Pointer Events so that we can implement and ship support in Chrome.

One of the main concerns I cited<https://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0051.html> with our decision not to implement is that the uncaptured-by-default model for touch input places a performance burden on the engine.  Since the dominant input APIs on touch devices (Touch Events, Android and iOS native APIs) don’t have this property, we are unwilling to adopt an API with this disadvantage, no matter how small.  In addition to the performance concerns, we believe an implicit-capture model encourages a style of UX we feel is most appropriate for direct-manipulation input devices - where, by default, the user is manipulating a specific object, not touching a layer of glass above all objects.

I feel the simplest way to address these concerns would be to make the following two changes to the API.  First, allow an implementation to implicitly capture touch (and perhaps pen) input to the target node on pointerdown (note that the spec already technically permits the browser to choose to capture implicitly since IE does this for button elements for example).  Developers can still use the explicit capture APIs to recapture elsewhere (as is often necessary to achieve the desired UX), or return to uncaptured events.  Second, add an optional parameter (false if unspecified) to setPointerCapture which indicates whether pointerover/out/enter/leave events are desired during capture.  When false, an implementation can avoid hid-testing for every move during capture.

Of course these are breaking changes, and it’s likely they could be a significant compatibility problem for existing websites.  I’m interested in implementing this model behind a flag and collecting data about the compatibility implications.  Perhaps it’s possible that Chrome could ship this with acceptable compat pain and move the web to using explicit APIs to indicate developer intent.  Then other PE implementations could update without much trouble.  I’m also willing to explore other ideas for mitigating the compatibility risk within our requirement that developers will be unlikely to accidentally incur per-move hit-test costs without explicitly opting into them.

Given the complexity, I’m guessing this is a topic best discussed on a call.  But I wanted to get our position stated clearly.  Feel free to reply here if you like, but regardless I’m sure we’ll discuss this in detail in coming teleconferences.

Thanks, and sorry for the frustration our changing position on Pointer Events has caused!  We really do want to do what’s best for the web platform here, and deeply value the collaborative and open standards process within the PEWG.
   Rick