W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2016

[pointerevents] Value of button attribute for pointermove event

From: Marius Stefan Bethge via GitHub <sysbot+gh@w3.org>
Date: Sun, 31 Jan 2016 22:30:42 +0000
To: public-pointer-events@w3.org
Message-ID: <issues.opened-130201932-1454279441-sysbot+gh@w3.org>
bethge has just created a new issue for 
https://github.com/w3c/pointerevents:

== Value of button attribute for pointermove event ==
We have noticed an inconsistency when it comes to the `button` 
attribute of a `pointermove` event 
(https://github.com/jquery/PEP/pull/267).

In IE 11 and Edge, any `pointermove`, that does not express a button 
state transition, has `button: -1`.

In OSX and Win - FF 44 (with flag) a `pointermove`'s `button` 
attribute mirrors the `mousemove`'s `button` attribute, with the 
extension of `button: -1`, if no button is pressed.

According to the specification: 
https://www.w3.org/TR/pointerevents/#chorded-button-interactions 
`button` and `buttons` are inherited from: 
https://www.w3.org/TR/DOM-Level-3-Events/#attributes-2, which states:
> The value of button is not updated for events not caused by the 
depression/release of a mouse button. In these scenarios, take care 
not to interpret the value 0 as the left button, but rather as the 
un-initialized value.

Is there an expected value of `button` for a `pointermove` with a 
button pressed and no button state transition? Is `button: -1` the new
 _un-initialized value_?

The current situation for `mousemove` is quite diverse and varies 
across OS and browsers, with `button: 0` for Win IE and Win FF and 
`button: 0/1/2` (matching the currently pressed button) for OSX 
Safari, OSX FF, OSX CH and Win CH. Might PE be an opportunity to form 
a consistent behaviour?

P.S.: The same holds for `pointerenter`, `pointerover`, `pointerleave`
 and `pointerout`.

Please view or discuss this issue at 
https://github.com/w3c/pointerevents/issues/33 using your GitHub 
account
Received on Sunday, 31 January 2016 22:30:45 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 January 2016 22:30:46 UTC