W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2014

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

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 13 Feb 2014 23:05:51 +0000
To: "Bjoern Hoehrmann (derhoermi@gmx.net)" <derhoermi@gmx.net>, Jacob Rossi <Jacob.Rossi@microsoft.com>
CC: "www-dom@w3.org" <www-dom@w3.org>, "Anne van Kesteren (annevk@annevk.nl)" <annevk@annevk.nl>, "olli@pettay.fi" <olli@pettay.fi>, "Gary Kačmarčík (Кошмарчик)" <garykac@google.com>
Message-ID: <2d351b54381e47f2a9ae0a39854fca1a@BLUPR03MB344.namprd03.prod.outlook.com>
* Jacob Rossi wrote:
>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.

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

Received on Thursday, 13 February 2014 23:06:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:22 UTC