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