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

Re: Add non-normative example section to mouse compatibility event mapping?

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Tue, 10 Dec 2013 16:25:28 +0000
Message-ID: <52A74078.1070008@splintered.co.uk>
To: Rick Byers <rbyers@google.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
To expand some more on this: I personally find 
https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#compatibility-mapping-with-mouse-events 
to be confusing, or at least not very internally consistent.

For example:

"Authors can prevent the production of compatibility mouse events by 
cancelling the pointerdown event."

This does not seem to be correct, as it seems that mouseover, 
mouseenter, mouseleave, mouseout cannot be prevented. So this should 
potentially be changed to "Authors can prevent the production of SOME 
compatibility mouse events..." ?

The note at the end of "11.1 Mapping for devices that support hover" 
does clarify this:

"Mouse events can only be prevented when the pointer is down. Hovering 
pointers (e.g. a mouse with no buttons pressed) cannot have their mouse 
events prevented. And, the mouseover and mouseout events are never 
prevented (even if the pointer is down)."

But perhaps, rather than having this long-winded note that explains all 
the things that can't be prevented, maybe turn it around into a much 
more terse

"Only mousedown, mousemove and mouseup can be prevented" ? (or am I 
misreading this?)

The same note is repeated at the end of "11.2 Mapping for devices that 
do not support hover" but in this context it doesn't seem to make sense, 
as it talks about hovering pointers in a section specifically about 
devices that don't support hover?

The actual essence of how events would be dispatched (say when the user 
taps on a touchscreen) seems to be there in the steps, but not in an 
easily graspable order. It would possibly aid comprehension if, at the 
end of the steps/algorithm, it had a few examples that then showed the 
event sequence, a la:

assuming the finger is primary, and we don't cancel the event when we 
get to pointerdown, the browser will fire the following

mousemove > pointerover > mouseover > pointerenter > mouseenter > 
pointerdown >
mousedown > (pointermove > mousemove if there's a slight movement of the 
finger) > focus > pointerup > mouseup > pointerout > mouseout > 
pointerleave > mouseleave > click

(maybe even include the gotpointercapture / lostpointercapture ones for 
completeness)

then an example where the finger is primary but we DO cancel the event 
(and maybe even show how it's intended to be cancelled - return false? 
event.cancelBubble? event.preventDefault?)

mousemove > pointerover > mouseover > pointerenter > mouseenter > 
pointerdown > (pointermove) > focus > pointerup > mouseup > pointerout > 
mouseout > pointerleave > mouseleave > click

P
-- 
Patrick H. Lauke
______________________________________________________________
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
______________________________________________________________
twitter: @patrick_h_lauke | skype: patrick_h_lauke
______________________________________________________________
Received on Tuesday, 10 December 2013 16:25:49 UTC

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