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

The nice thing about implicit capture is that it avoids a set of bugs that
developers often overlook. For example, when creating a custom draggable
widget, every developer's first thought is to just bind all events to the
draggable element. Without implicit capture, it's possible to move too
quickly and end up with events being sent to other elements, which can
result in a complete lack of response as the element is no longer receiving
events and therefore stops moving. Because this involves quick movement,
it's often not discovered in initial testing, but rather once the code has
shipped to production. This is the basic logic for several interactions. On
the other hand, in any scenario where implicit capture would prevent the
intended behavior from working, the developer will notice instantly and be
able to fix the mistake.

It will be interesting to see what happens to existing content though if
the default behavior changes. I wouldn't be too surprised to find out that
it's mostly a non-issue though. Do we have a list of popular use cases that
require not capturing?

On Wed, Mar 25, 2015 at 2:58 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

>  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
>
>
>