W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ISSUE-30: mousewheel event

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Thu, 02 Mar 2006 03:00:51 -0500
Message-ID: <4406A633.9060603@earthlink.net>
To: Jonas Sicking <jonas@sicking.cc>
CC: "Web APIs WG (public)" <public-webapi@w3.org>

Jonas Sicking wrote:
> Matthew Raymond wrote:
>> Anne van Kesteren wrote:
>>> On Sun, 26 Feb 2006 06:55:48 +0100, Matthew Raymond  
>>> <mattraymond@earthlink.net> wrote:
>>>> If the wheel doesn't scroll, why would you want it to trigger the
>>>> event in the first place???
>>>
>>> So you can use it for zooming instead. (If there is a scrollbar you could  
>>> do this by canceling the event...)
>>
>>    I don't get it. While you may use the mouse wheel for the purpose of
>> zooming, the event it should trigger should be something like
>> "mousezoom". 
> 
> No, this would amount to way too many events. Basically you'd get N*M 
> events where N is the number of input devices (stylus pens, keyboard, 
> mouse, etc) and M is the number of things they can do (scroll, zoom, click).
> 
> This is, of course, undesirable.

   You misrepresent the situation. There are a finite number of
operations you can perform with an input device no matter what it does.
The term "mouse" doesn't refer to a specific class of input devices. It
just refers to the fact that the event is related to the pointer.

   Providing events for all possible physical controls on an input
device just doesn't make sense no matter how few functions each control
can potentially perform. Think about the controller for Steel Battalion.
 The think has two joysticks, three pedals, a throttle and something
like several dozen buttons and switches. If we have even one event for
every control on that controller, you're already at something like a
hundred events.

   So how does a game handle this? It has a finite number of events that
are then bound to whatever inputs the user wishes. Similarly, we need to
 have DOM events for the functions the user is trying to perform and not
the controls that the user might have on their input device.

> What is being proposed is this: The 'mousewheel' event is an event 
> similar to 'mouseclick' or 'keydown'. It is fired in response to the 
> user using a 'wheel' on his/her mouse.

   That's not how I'd define it. The "mousewheel" ("DOMMouseScroll")
event occurs when the user attempts to scroll the element under the pointer.

> When the event has fired (assuming preventDefault() wasn't called) the 
> UA will perform an action associated with the mousewheel. In many UAs 
> today that will scroll the displayed page. In response to this scrolling 
> a 'scroll' event is fired. If the UA had instead been configured to zoom 
> in response to the wheel a 'zoom' event might fire.

   I would argue that scrolling the hovered element and scrolling the
focused element are two different types of events. This is why I think
"mousescroll" is more appropriate. The name "mousewheel" simply has more
traction.

> This is exactly like how things work when you use the mouse buttons. 
> When the user clicks the mousebutton over a <input type=submit> element 
> a 'click' event is fired and then a 'submit' event in response to the 
> 'click'.

   Someone could configure a keyboard shortcut to trigger a "click"
event. Physical controls in are meaningless because the input can be
abstracted on multiple levels. What keyboard shortcut or button or wheel
or pedal or joystick or throttle I choose to bind the "click" event to
is none of the web application programmer's business. What's important
is the definition of the event, not how you trigger it.

> This way, someone interested in using the mousewheel to for example 
> control a character in a game will just have to listen to the 
> 'mousewheel' event and call .preventDefault() on it. It does not have to 
> worry about if the UA would normally scroll, zoom or do something else.

   If we define events to be too control-specific, we end up favoring
specific platforms that support that control at the expense of those
that don't.

> Similarly, someone that is interested in reacting to scrolling will just 
> have to listen to the 'scroll' event and doesn't have to care if the 
> scrolling came from an arrow-key keyboard press, a mousewheel roll, or a 
> mouseclick on the scrollbar.

   Again, I think we're talking about two distinct types of scrolling. I
would agree that scrolling not related to the pointer position should
result in a "scroll" event.
Received on Thursday, 2 March 2006 08:00:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:53 GMT