- From: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Date: Thu, 5 Jun 2014 20:39:18 +0000
- To: "Patrick H. Lauke" <redux@splintered.co.uk>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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. -----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
Received on Thursday, 5 June 2014 20:40:01 UTC