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

* Jacob Rossi wrote:
>From: Bjoern Hoehrmann <[email protected]>
>> * Jacob Rossi wrote:
>>>From: Bjoern Hoehrmann <[email protected]>
>>>> 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.

I moved the bug for this issue to the DOM L3 Events component, and just made the 
change in DOM 3 Events from button of type unsigned short to button of type short. 
Hopefully this will accomoadate the Pointer Events specification.

Bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20236
Change diff: https://dvcs.w3.org/hg/dom3events/rev/bfce9a135d6e