W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2013

Impact of pointer capture on pointerover/pointerout events

From: Rick Byers <rbyers@google.com>
Date: Fri, 26 Apr 2013 16:32:10 -0400
Message-ID: <CAFUtAY-=pRvTLvsXnk3-H-cD7=GC_xxk1zTEZzXESzpQJFvnOA@mail.gmail.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC