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

Re: ISSUE-30: mousewheel event

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 02 Mar 2006 13:46:38 -0800
Message-ID: <440767BE.7060403@sicking.cc>
To: Matthew Raymond <mattraymond@earthlink.net>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>

>    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.

You don't need an event for every possible key that can be pushed. 
Consider keyboards, they have over a hundred buttons but two events 
(keyup, keydown) are enough to cover them all.

>    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.

When I configure Doom I don't say that 'switch weapon' should be tied to 
'scoll' or 'mousescroll'. I say that it should be tied to the 
mousewheel. And is how I want it to be because if I change my windows 
manager to scroll on ctrl+up/down I still want doom to switch weapon on 
the mousewheel.

>> 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.

*sometimes* physical controls are meaningless. But sometimes they are not.

That is why we fire two events. One to let page know that they user 
rotated the mousewheel so that if you care about physical controls (like 
in a game) then you can react to that and make the monkey jump over the 
monster.

And we fire a 'scroll' event so that if you want to position the <div> 
at the top of the viewport then you have a chance to do that.

>> 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.

If you only care about positioning your <div> at the right place then 
you don't care how the page was scroll. You only care that the page was 
scrolled. No matter how many controls could possibly cause it to scroll.

/ Jonas
Received on Thursday, 2 March 2006 21:44:45 GMT

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