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

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

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 22 Jan 2013 13:03:33 +0100
To: Jacob Rossi <Jacob.Rossi@microsoft.com>
Cc: Travis Leithead <travis.leithead@microsoft.com>, Anne van Kesteren <annevk@annevk.nl>, "www-dom@w3.org" <www-dom@w3.org>, "olli@pettay.fi" <olli@pettay.fi>
Message-ID: <fgvsf89jv57n2rqvtkeianh3ak64ov3euo@hive.bjoern.hoehrmann.de>
* 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. 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.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Tuesday, 22 January 2013 12:04:01 UTC

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