- From: Rick Byers <rbyers@google.com>
- Date: Fri, 6 Jun 2014 00:14:20 -0400
- To: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>, Matt Brubeck <mbrubeck@mozilla.com>
- Message-ID: <CAFUtAY98a3_71e3XaQgfvuz1Q7Fb73CPJVSa1XykCf6gHAoOpw@mail.gmail.com>
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. 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. 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.... Rick On Thu, Jun 5, 2014 at 11:30 PM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote: > I doubt other browsers will do this. So I'm wary of adding a note just for > IE. We might even change our behavior to not fire the events. Rick/Matt, > thoughts? > > -----Original Message----- > From: Patrick H. Lauke [mailto:redux@splintered.co.uk] > Sent: Thursday, June 5, 2014 7:32 PM > To: public-pointer-events@w3.org > Subject: Re: gotpointercapture/lostpointercapture on <button>s in IE > > On 05/06/2014 21:39, Jacob Rossi wrote: > > Most browsers intrinsically take a form of capture when you click a > control (provides a better touch experience if your finger slips a bit as > it lifts in a tap, for example). IE essentially does this by setting > pointer capture. We just didn't do the work to special case this such that > the events don't fire (though, arguably, it's good that they do). I think > this is more of an implementation specific kind of thing that doesn't > really belong in the spec. > > Thanks Jacob, that's useful to know. Wonder if it's worth adding a tiny > note to the spec just to warn devs that they may indeed see those events > firing in these situations? Doesn't have to go into details, but something > generic as your explanation above could avoid confusion/surprise? > > P > > > -----Original Message----- > > From: Patrick H. Lauke [mailto:redux@splintered.co.uk] > > Sent: Wednesday, June 4, 2014 10:35 AM > > To: public-pointer-events@w3.org > > Subject: gotpointercapture/lostpointercapture on <button>s in IE > > > > Possibly an implementation-specific question for Jacob, but I was > > wondering: in IE, it seems that tapping a <button> element (and > presumably other specific elements like <input>s) fires gotpointercapture > and lostpointercapture by default, without any programmatic setting of > pointer capture (but if I swap out the element for, say, a <div> these > events don't fire by themselves unless I explicitly set pointer capture). > > > > This behavior doesn't seem to be documented in the current PE spec. Can > I just check what the rationale behind IE's firing of those events on those > types of elements is? Want to make sure it's not something we should be > including (and yes, I'm just morbidly curious anyway). > > > > Cheers, > > > > 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 > > > > > > > -- > 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 04:15:09 UTC