Re: ISSUE-30: mousewheel event

Jim Ley wrote:
> "Matthew Raymond" <mattraymond@earthlink.net>
>>> MouseScroll is a bad name too, for mice with multiple scrollwheels, not 
>>> all
>>> of them generally scroll, nor is there always an inherent relationship
>>> between wheels and scrolling, just a common one.
>>   If the wheel doesn't scroll, why would you want it to trigger the
>> event in the first place???
> 
> If it does scroll, why would I want it to?  they're equivalent statements 
> really.

   I didn't mean the physical "scrolling" of the wheel. I meant the
scrolling of an OS widget or window under the mouse pointer.

> I want to catch events from input devices to override the default 
> behaviour.  Whatever the default behaviour is is irrelevant.

   So if I have my mouse set up to switch applications when I move the
mouse wheel, the BROWSER should prevent me from doing so and instead
hand that input off to a Javascript function?!? Get real!

>> For instance, I have a button on the side of
>> my mouse that's mapped by the mouse settings to the "middle button". My
>> mouse doesn't actually have a middle button, because I have a scroll
>> wheel there instead (although, technically that could be used as a
>> button as well).
> 
> So on mousedown I would expect to get information that you mousedown'd with 
> such a button, why would you not?

   If the OS doesn't have the button configured to trigger mouse-related
events, those mouse-related events shouldn't be passed to the browser,
let alone a Javascript event function.

>> If I
>> configure my mouse wheel to be an "Undo" button, it should trigger a
>> "mousewheel"-type event in the first place.
> 
> Of course it should, although you may want to configure your OS to hide it 
> from the browser entirely.

   If I configure it to be "Undo" in my mouse configuration software, it
 _IS_ hidden from my browser entirely. That's the whole point. There is
a potential layer of abstraction between the physical input hardware and
the events sent to applications that makes it impossible to know for
certain that a specific type of physical control gave the input.

>> and the event in question occurs
>> to the element under the pointer device, so it's clear that the first
>> half of this event should be "mouse".
> 
> Is it clear that the wheel goes to the thing with [mouse focus] and not the 
> focus?  I'm pretty sure when forms have focus in IE it goes with focus, so I 
> would've thought it would always go with focus there.  That needs research.

   I did a quick test with two <textarea> elements. Scrolling the
unfocused <textarea> using the mouse wheel in both IE and Mozilla did
not cause the element to take focus from the focused <textarea>.
Scrolling using the mouse wheel only scrolled the element under the
mouse pointer, not the focused element. If the mouse wheel only scrolled
the focused element, regardless of the pointer location, we wouldn't
need "mousewheel" anyways, because we could just use the "scroll" event.

Received on Tuesday, 28 February 2006 22:38:03 UTC