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

I'm really glad to here there's UX support for implicit capture from the
frameworks - thank you!  I've heard similar feedback from Angular.js folks
(mainly saying they'd always explicitly capture - so they're happy as long
as there is a good explicit capture API).

I was thinking (to mitigate the compat risk somewhat) we might want
implicit capture just for touch.  But this makes it sound like we should
probably make an effort to try to keep all input types consistent in this
regard.  Of course the ultimate decisions here will probably be made based
on hard data from compat testing.

I wonder how often sites are already relying on explicit capture anyway?
It'll sure be interesting to see how often sites are broken by an implicit
capture model.  It's obviously going to take us awhile to get a blink
implementation up to the point we can really test this...

I should add that it makes total sense that PE was designed to be
non-capture by default.  One of the properties that initially attracted me
to PE was that it was a minimal extension of Mouse Events.  At the time I
was personally focused on trying to get existing websites to invest in
adding some minimal support for touch input.  Now the world seems a lot
different, I no longer put much value on the 'easy to migrate mouse event
code' property.  If your site isn't designed for touch in some fashion by
now, then I think you're unlikely to be investing in changing your site to
use pointer events anyway.  In general I think we should be focused on the
API we want the web to have long-term, and try to restrict our compat
concessions only to the behavior of 'legacy' event types.  Of course
breaking changes are still a problem - but let's not loose site that it's
still a lot easier for us to make breaking changes here now then it will be
in 5-10 years.  In the timescale of the web, PE is still in its infancy :-)

Rick




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

> On Wed, Mar 25, 2015 at 3:31 PM, Daniel Freedman <dfreedm@google.com>
> wrote:
>
>> 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`.
>>
>
> The tricky part about global opt-in is that it means no library can ever
> assume one model or the other and must always be explicit anyway. And of
> course any library which isn't explicit may break on a site that changes
> the global behavior.
>
> Assuming we don't come across common scenarios that break with implicit
> capture, we may just expect libraries to eventually assume implicit capture
> and explicitly code for the cases where they don't want that. This is
> similar to libraries needing to adapt to `* { box-sizing: border-box }`
> being used on more and more sites.
>