RE: [DOM3Events] Pointer Events request to change DOM 3 Events "button" type

From: Bjoern Hoehrmann <derhoermi@gmx.net>
> * Jacob Rossi wrote:
>>From: Bjoern Hoehrmann <derhoermi@gmx.net>
>>> http://www.w3.org/TR/2013/WD-pointerevents-20130115/ proposes "In 
>>> order to facilitate differentiating button state transitions in any 
>>> pointer event (and not just pointerdown and pointerup), the button 
>>> property takes on a new value when no mouse buttons are depressed" 
>>> specifically the value -1 would be for "Mouse move with no buttons 
>>> pressed". So, for 'mousemove' with no button pressed you will get 
>>> MouseEvent.button == 0, while for "pointer events" you get MouseEvent.button == -1?
>>
>>Trusted mouse* events will not change (preserving compat).  So for a 
>>mousemove, you'll get 0. But for pointermove you would get -1.
>
>Expressing the same state through the same interface using two mutually exclusive attribute values strikes me as bad interface design. 

It's not the same type.  When the "-1" model is used, the object will be a PointerEvent. When the "0" model is used, the object will be a MouseEvent.  

> So does using the value -1 for this more generally, and using magic numbers here more generally; using a bitmask in `MouseEvent.buttons` is not much of an improvement, but given `MouseEvent.buttons`, I do not see why using the `-1` value in `MouseEvent.button` is necessary or desirable. Perhaps the Pointer Events Working Group could make a better argument for this design than pointing out that they "want it"? Then we could come up with alternatives and evaluate them.

The idea is to move towards a model where buttons are simply a modifier of the pointer state. "down" versus "up" events connote the "active" state of a pointer (like :active from CSS), and the specific buttons depressed are simply modifiers of this state. So we want the true button state to be detectable on any event (because, in this model, they're modifiers).   

The mouse event model is such that you can't differentiate a value of "0" that means a primary button just changed from a value of "0" that just happens to be the default value of the property on events where the button state would not have changed (e.g. mousemove). So we introduce a new value when firing pointer events, -1, that means the button modifier state is unchanged from the last event. We went with -1 because we wanted to maintain the definitions that 0 means primary (left), 1 is middle, 2 is right, etc. This makes it easier to transition mouse event code to pointer event code.

Received on Thursday, 24 January 2013 19:32:17 UTC