24777 2014-02-22 20:55:28 +0000 Add tiny note to 11.2 - list item nr 2 (mousemove) to clarify the reason for it 2014-03-04 01:36:29 +0000 1 1 1 Unclassified PointerEventsWG Pointer Events specification unspecified PC Windows NT RESOLVED FIXED P2 normal --- 1 redux jrossi public-pointer-events public-pointer-events-bugzilla oldest_to_newest 101205 0 redux 2014-02-22 20:55:28 +0000 Currently 11.2 item 2 reads: "If the pointer event to be dispatched is pointerover and the pointerdown event has not yet been dispatched for this pointer, then fire a mousemove event." I wonder if it's worth adding a tiny clarification right at the end, to explain that this is done purely for compatibility (I usually call this a "sacrificial" mousemove when talking about touch events' mouse compat) "If the pointer event to be dispatched is pointerover and the pointerdown event has not yet been dispatched for this pointer, then fire a mousemove event (for compatibility with legacy mouse-specific script)" or similar? 101314 1 jrossi 2014-02-25 07:41:38 +0000 I figured this was covered by the following in 11.2's introduction: "Much existing content coded to mouse events assumes that a mouse is producing the events and thus certain qualities are generally true: •The input can hover independently of activation (e.g. moving a mouse cursor without any buttons pressed) •The input will likely produce the mousemove event on an element before clicking it" If you don't think that's enough, I don't mind adding something inline as you suggested. 101808 2 jrossi 2014-03-04 01:36:29 +0000 Change added as discussed in 2/25 telecon and in this bug: https://dvcs.w3.org/hg/pointerevents/rev/11bba6e52c03