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

In total agreement with Rick and Scott that implicit capture is a much
simpler model to think about for many use cases.

If it is simpler, perhaps there can be a "global opt-in" for a page to have
implicit capturing enabled?
Something like PointerEvents.setImplicitCapture(), which implicitly calls
setPointerCapture and dispatches a `gotpointercapture` event on every new
`pointerdown`.

On Wed, Mar 25, 2015 at 12:12 PM, Scott González <scott.gonzalez@gmail.com>
wrote:

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