- From: Rick Byers <rbyers@google.com>
- Date: Fri, 26 Apr 2013 16:32:10 -0400
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
- Message-ID: <CAFUtAY-=pRvTLvsXnk3-H-cD7=GC_xxk1zTEZzXESzpQJFvnOA@mail.gmail.com>
The spec for setpointercapture says "Subsequent events for the pointer must always be targeted at this element.", and the spec for pointerover says "A user agent must dispatch this event when a pointing device is moved into the hit test boundaries of an element". I think there's some detail missing here. Consider the following scenario: a pointer moves from disjoint element A to element B while captured to A. According to the specs (and inferring some details from the mouse event spec), without capture I'd expect maybe the following sequence of over/out (and equivalent enter/leave) events: pointerout target=A currentTarget=A relatedTarget=B pointerover target=B currentTarget=A relatedTarget=A But with capture these events should all go to A. So presumably pointerover event 'target' property should now be 'A'. Then how do I tell that the pointer just went over element B? The event ends up being pretty useless (you went over something, but we're not telling you what). On a quick test (http://www.rbyers.net/eventTest.html with the pointer events and capture settings enabled), IE10 solves this by not dispatching the useless events: - an over event is dispatched only when going over element A - an out event is dispatched only when leaving element A Should we explicitly specify that? Also should we explicitly specify the meaning of relatedTarget for the pointer events analogous to the mouse events? The only place we mention relatedTarget is to say that it's always null for a pointer being captured. Rick
Received on Friday, 26 April 2013 20:32:57 UTC