Re: gotpointercapture/lostpointercapture on <button>s in IE

On 06/06/2014 05:14, Rick Byers wrote:
> Interesting.  It seems possible that websites could be broken by this
> behavior in either case: they might not expect a gotpointercapture when
> they don't think there's any code running that explicitly requests it,
> or they may be surprised to see events that are behaving as captured
> even though they never got a gotpointercapture event.

Yes, after having had my fair share of automagic undocumented behavior 
(mostly from iOS/Safari) when it comes to touch events, I'd favour the 
path of least developer surprise, even if it just means adding a 
non-commital, fluffy, generic note at the end of the first bit of "10. 
Pointer Capture" (after Fig 4)  to the effect of:

"NOTE: browsers MAY implement their own implicit pointer capture 
behaviour - for instance, for touch interactions, a browser may 
automatically capture the pointer as part of a tap on a native form 
control to allow for improved user interaction. As part of this 
behaviour, browsers MAY fire <code>gotpointercapture</code> and 
<code>lostpointercapture</code> events, even when no explicit pointer 
capture functions (<code>setPointerCapture</code> and 
<code>releasePointerCapture</code>) were called."

(or something similar anyway)

> I think the guiding principle here should be that the browser controls
> aren't fundamentally special compared to controls implemented by a
> library (especially one using web components and custom elements - which
> is effectively how our built-in controls are implemented in blink).  So
> since a JS control library would invoke setPointerCapture here resulting
> in gotpointercapture events, then so should the browser for built-in
> controls.

I agree with this general principle as well (sounds very "extensible web 
manifesto") and it ties up neatly with some of the discussions we (Rick 
and I) had with Jorik Tangelder (creator of Hammer.js 
http://eightmedia.github.io/hammer.js/).

> So then should we have a note about this?  I'm not sure.  The general
> principle is that one component always needs to be prepared for another
> component to decide to capture events (regardless of whether it's the
> browser, some browser extension running in your page, or just a library
> that's part of your page).
>
> By the way, if the browser is free to do this and it doesn't break web
> pages in practice, then maybe it's not as breaking as I thought for some
> browser to decide to capture ALL pointer events for touch to the touched
> element by default.  This is what Adam Barth was arguing was better
> about TouchEvents.  If we could reasonably decide that browsers are free
> to implement auto-capture whenever they like (and we thought it was
> reasonable for pages to deal with this - explicitly clearing capture
> when needed), then that would eliminate one of the big barriers to
> adding PointerEvents to chrome....

Oh, interesting. I do wonder if some browsers will indeed opt (once they 
go for PE) for this form of auto-capture to make the model more similar 
to Touch Events (at least for touch interactions). We certainly don't 
want to make this behavior normative, but perhaps having an informative 
note with a "MAY" strikes a reasonable middle ground between 
undocumented implementation-specific behaviour and developer 
awareness/documentation/warning. And the fact that this note would 
immediately "bless" what IE is actually doing at the moment is a good 
thing in my book.

(Anecdotally, if *I* was surprised by the fact that I was seeing 
gotpointercapture/lostpointercapture in my normal event flow, 
considering I've been quite close to the spec and played around with it 
a lot, I can imagine devs being new to this events model being even more 
caught out by it).

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Friday, 6 June 2014 08:38:21 UTC