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
