Pointer Events and mouse compatibility events

Is it just me, or does 
actually not make much sense?

The implication, if I read the spec correctly, is that the mouse 
compatibility events can be suppressed by cancelling pointerdown, so the 
mouse events shouldn't actually be fired until AFTER pointerdown, 
presumably in the sequence (assuming a finger tap on a button):

pointerover > pointerenter > pointerdown

and then, unless at this point the event was cancelled...something 
sensible that fires the equivalents for the above

mouseenter > mouseover > mousedown

followed by whatever else happens, like

pointermove > mousemove > pointerup > mouseup > pointerout > mouseout > 
pointerleave > mouseleave


The language used in the spec seems quite obtuse here. Is anybody else 
reading it differently?

And for what it's worth, IE10 and IE11 do something quite different - 
tapping on a button on 
gives me (normalising away the vendor-prefix in 10)

mousemove > pointerover > mouseover > pointerenter > mouseenter > 
pointerdown > mousedown > pointermove > mousemove > pointerup > mouseup 
 > pointerout > mouseout > pointerleave > mouseleave

(i.e. first a stray mousemove, then the pointer and compatibility mouse 
events fired "inline" one straight after the other / intermingled)

Now I understand that the spec talks about "MAY", so IE's implementation 
could well be idiosyncratic - since the spec doesn't say anything 
normative here...but the intermingling seems far more logical to me, 
though it raises the question how the compatibility events could be 
prevented (it seems the "cancelling pointerdown" thing from the spec 
doesn't work, or I've been doing it wrong).


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 Monday, 2 December 2013 23:51:01 UTC