RE: Proposal for mousewheel events

Hi-

Sjoerd Visscher wrote:
|
| This could simply be solved by not allowing a redraw between 
| the 2 events.

I'm not sure how that applies to the use case I mentioned. I got especially
confused when this thread went off into XHR... 


| I don't want to argue about the details here. There is *something* in 
| Firefox that prevents layout and painting in the simple cases, which 
| should be good enough for doing smooth diagonal scrolling with 2 
| separate events.

Let me reiterate: the wheel event (a device input) is not the scroll event
(an abstracted UI event).

I must not have presented my use case clearly enough. Let's say I have a
"wheel", such as a mini-trackball atop a mouse, that can move any direction.
As an author, I want to capture the movements of this wheel to let the user
tweak the position of a bezier-curve handle (because the discrete units of
the wheel allow greater control than the mouse). If there are 2 separate
events, I will have to capture both of them and coordinate them such that
they don't contradict one another as to the new position of the handle. Or,
for instance, a game that is a tight maze, where you lose if you touch the
sides; registering 3 units left and 5 units up as individual actions is not
likely to produce the same results as taking them as a vector, and would
probably result in a collision.

I know that this is a different definition of a wheel than the simple
scrollwheel that IE addressed in earlier browsers, but this is the reality
of hardware now: wheels are more complex, and need a more sophisticated
event model.

I propose that we leave "mousewheel" to be implemented by browsers as they
already do, if they wish, and preserve the compatibiltity with legacy
content. My alternate proposal is that we specify a new event, the "wheel"
event, which has the new properties of separate ".details" and ".wheelDelta"
for the horizontal and vertical axes, while keeping. This is not to say that
every wheel will have both axes, but it allows for the possibility; it harms
no legacy content, and would be a consistent method that is unlikely to
change in the future, since it would cover all directions.

A related idea is to indicate which wheel this is, on a device with multiple
wheels. I think that this could be captured in a similar way as e.g.
"click.button", with a "event.device". "device" would be a enumeration of
the connected devices (0 for the primary device, 1 for the secondary, etc.) 

So, you would have:
 event.x.details
 event.y.details
 event.x.wheelDelta
 event.y.wheelDelta
 event.device

You would also have booleans for altKey, ctrlKey, metaKey, and shiftKey, as
Maciej suggested. It might also be nice to have "target" exposed so that if
the wheel *is* attached to the pointer device, you could grab the currently
focused object to receive the events.

Regards-
Doug

Received on Tuesday, 11 April 2006 20:01:56 UTC