RE: pointermove dispatching when button state changes

The "button state" clause here is simply to satisfy the chorded button scenario [1]. In a simple mouse click, there's no pointermove (pointerdown, pointerup provided the button state change). But in the case of chorded (overlapped) button presses, you need an event to update the button state (pointermove).

As a part of how we tackle "buttons attribute bitmask is painful" in V2 [2], I think we'd want to consider having a discrete event for this scenario (e.g. pointerbuttonchange or something).

-Jacob

[1] https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#chorded-button-interactions
[2] http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements#Requirements:_Pointer_Events_v.Next_Specification

From: Scott González [mailto:scott.gonzalez@gmail.com]
Sent: Friday, May 3, 2013 7:46 AM
To: public-pointer-events@w3.org
Subject: pointermove dispatching when button state changes

The spec currently says "A user agent must dispatch this event when a pointer changes coordinates, button state, pressure, tilt, or contact geometry (e.g. width and height)."

Does this mean that when using a mouse, a click will always generate a pointermove event? I would expect pointerdown, pointerup, click, which is the behavior we see with mouse events.