- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Tue, 10 Dec 2013 16:25:28 +0000
- 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