W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2003

MouseEvent and buttons

From: Rowland Shaw <Rowland.Shaw@crystaldecisions.com>
Date: Wed, 17 Dec 2003 12:15:38 -0000
Message-ID: <F20B32C3798696419320BEFAADB32AB01AC9F9@ipsexch03.crystald.net>
To: "'www-dom@w3.org'" <www-dom@w3.org>

Trying not to re-open war wounds, but:
 
I'm looking at an issue related with some dragging code used in a DHTML
application. Basically we don't get mouseup events from Mozilla based
browsers if the mouse button was lifted out of the document area.

The current implementation uses 2^event.button and uses this as a bit mask
to store the current mouse state on a variable held on the window (the more
observant reader may spot that this then gives a value equivalent to MSIE's
event.button property). The intention is that when we receive a mousemove
event (say, the mouse moving back over the document) we can validate the
current our state based on the state of the buttons.

The closest we've found is to treat onmouseout as an onmouseup which is not
elegant nor accurate.

To move to the point; Given this scenario (and other like it that throw up
after a quick Google search) could it be considered to:
* extend the interface to include a button mask -- an implementation is out
there (in the form of MSIE, albeit using the "button" property and MSIE not
claiming support for DOM Events per W3 Spec)?
* extend the mousemove context info to include the [most recently] pressed
mouse button? (and spec for "-1" (for example) to represent no button
pressed)

Given the current state of play there are many things that are not workable
due to the lack of mechanism to examine the current state of play.

Thoughts and comment welcome,

Best wishes,
 Rowland Shaw
Received on Wednesday, 17 December 2003 07:19:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:57 GMT