W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2013

RE: pointermove dispatching when button state changes

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Tue, 7 May 2013 03:17:12 +0000
To: Scott González <scott.gonzalez@gmail.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-ID: <1e3763864f53439b9d6a712df281b012@BN1PR03MB267.namprd03.prod.outlook.com>
The "button state" clause here is simply to satisfy the chorded button scenario [1]. In a simple mouse click, there's no pointermove (pointerdown, pointerup provided the button state change). But in the case of chorded (overlapped) button presses, you need an event to update the button state (pointermove).

As a part of how we tackle "buttons attribute bitmask is painful" in V2 [2], I think we'd want to consider having a discrete event for this scenario (e.g. pointerbuttonchange or something).


[1] https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#chorded-button-interactions
[2] http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements#Requirements:_Pointer_Events_v.Next_Specification

From: Scott González [mailto:scott.gonzalez@gmail.com]
Sent: Friday, May 3, 2013 7:46 AM
To: public-pointer-events@w3.org
Subject: pointermove dispatching when button state changes

The spec currently says "A user agent must dispatch this event when a pointer changes coordinates, button state, pressure, tilt, or contact geometry (e.g. width and height)."

Does this mean that when using a mouse, a click will always generate a pointermove event? I would expect pointerdown, pointerup, click, which is the behavior we see with mouse events.
Received on Tuesday, 7 May 2013 03:19:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC