- From: François REMY <francois.remy.dev@outlook.com>
- Date: Sat, 13 Apr 2013 11:06:10 +0000
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
- Message-ID: <DUB405-EAS3925B0296CF2E89FA3C7310A5C20@phx.gbl>
Hi, Here’s a test case for your consideration where, I believe, IE10 is distant from the official specification: <!doctype html> <html onmspointerdown="eatPointer(event.pointerId)" onmspointermove="if(event.button>=0) console.log(event.clientX+','+event.clientY)"> <head> <title>Some pointer events test</title> <script> var x = document.createElement("div"); function eatPointer(id) { x.msSetPointerCapture(id); // will throw } </script> </head> <body> </body> </html> I believe the spec does not say the capture should fail, and therefore it should not. That would mean, however, that the capture may end up happening on a different window than the one the event was fired for, something which can be a problem. My ideas would be to clarify that the pointer capture can only be set (1) on elements which are attached to a DOM document, (2) on elements which belong to some specific DOM document (like the document for which the current event has been throw for), or (3) to leave the spec as is but adapt IE’s implementation accordingly. If we go to the ‘capturePointer(element?)’ and ‘releasePointer(element?’) on the PointerEvent object, it would probably best to go the (2) way. For the cases where you need outside-event pointer capture (let’s say in a rAF loop or after a valid gesture start) we could keep the element.setPointerCapture(id) and element.releasePointerCapture(id) methods but their use should be limited to those specific use cases. Then, we can define event.capturePointer() to capture the pointer on the event’s target and event.capturePointer(element) to set the capture to the element only if the capture isn’t set to a child of the element, which would be a very sane behavior for most use cases. François
Received on Saturday, 13 April 2013 11:23:39 UTC