- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Fri, 06 Jun 2014 09:38:09 +0100
- To: public-pointer-events@w3.org
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