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?


> -----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 Thursday, 5 June 2014 23:32:20 UTC