Re: Please Review: Mousewheel Event Proposal

Hi, Olli-

Thanks for your comments.  Replies inline...

Olli Pettay wrote (on 3/18/08 6:29 PM):
> 
> "It should allow authors to override the default action for either x or 
> y activity independently. "
> I think also z.

Yes, added.


> It is open what wheelDelta means. Is it "mousescroll clicks"?
> Moving finger over touchpad?

Yes, it has to stay open, because it is device- and system-dependent and 
usually user-configurable.

I also changed "clicks" to the more generic "rolls", to avoid confusion 
with the mouseclick event.


> But what if system can generate several kinds of data - line scrolling 
> and pixel scrolling, maybe even page scrolling or screen scrolling.
> Should we have different event names for different kinds of scrolling.

That is a related matter, but should be defined in the 'scroll' event 
[1], not the 'mousewheel' event.  I'll write some tests to see what 
browsers do.  Anyone else is also welcome to help with this, or report 
findings you've already made.

As far as I can see, the 'scroll' and 'DOMScroll' event don't have any 
specific properties, but maybe we could add some, like 
scrollEvent.mode="line | pixel | page | screen".  Or perhaps it could be 
quantified in scrollDeltas, or reflect the window.scrollX/scrollY or 
window.pageXOffset/pageYOffset.  I'm open to any suggestions, as long as 
we keep it simple.



> Should web application know somehow that what is the default action of
> mouse wheel scrolling: scrolling or zooming...
> On my browser ctrl+wheel is zoom, alt+wheel is slower-than-normal-
> scrolling.

The 'mousewheel' event is separate from the 'scroll' event, though the 
default action of the 'mousewheel' event is normally to throw a 
subsequent 'scroll' event.  We clearly need to define this relationship 
better.

We also clearly need to better specify the 'scroll' event; in addition 
to generation by a 'mousewheel' event, it may also be triggered by using 
the scrollbars or arrow keys, or by a script-generated event, for 
example.  It also doesn't seem to have


(It might be useful to let the user know where the 'scroll' event was 
generated, whether from a scrollbar, mousewheel, arrow-key, generated 
event, etc.... sorta like keyLocation...  No, wait, they can more or 
less already do that by listening for those other events.  Never mind, 
thinking out loud.  Well... hmm... given that we may at some point allow 
multiple mouse inputs simultaneously, for multi-touch inputs, or devices 
like the Wii, maybe... no, no, no.)


> "For both mouseomniwheel and mousewheel,
> MouseEvent.relatedNode must indicate the element over which the
> pointer is located"
> Why? element.target should indicate that already.
> 
> MouseOmniWheelEvent needs some examples. In which case is that event used?

MouseOmniWheelEvent was part of the other, original, much more 
complicated proposal.  I've updated the wiki to make it more clear that 
there are 2 different proposals.


[1] http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-scroll

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Received on Wednesday, 19 March 2008 02:24:58 UTC