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

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


On Thu, Jun 5, 2014 at 11:30 PM, Jacob Rossi <>

> 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 []
> Sent: Thursday, June 5, 2014 7:32 PM
> To:
> 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 []
> > Sent: Wednesday, June 4, 2014 10:35 AM
> > To:
> > 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
> >
> > |
> > |
> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
> >
> >
> --
> Patrick H. Lauke
> |
> |
> twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Friday, 6 June 2014 04:15:09 UTC