Doug Schepers wrote:
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.
The information should be in the 'wheel' event. It is the hardware/OS
which may generate different kinds of data.
Apparently some OSX systems create mouse wheel events (I'm not talking
about DOM event here), which may contain normal delta (deltaX/Y) but
also pixel scrolling delta (deviceDeltaX/Y).
Currently Safari seems to use also those pixel scroll events, but it
doesn't dispatch DOM events for those (if my test it correct and I've
read the code right. I don't have a mac). This breaks wheel handling
quite badly in some cases - random-like zooming/scrolling:
http://mozilla.pettay.fi/moztests/gmaps.html
http://mozilla.pettay.fi/moztests/pixelscrolling.mov
(thanks to Markus Stange for testing this)
I think we should first define a proper wheel event and after that
*maybe* specify the current wheel/mousescroll events.
The latest proposal looks pretty good, though the event name shouldn't
probably be 'mousewheel'. To not to break backward compatibility it
could be just 'wheel' or something. The new event should also handle
cases like pixel scrolling.
Implementations could continue supporting the old
mousewheel/mousescroll events. First dispatch the new event and then the
old event. If webapp gets the new style of event, it knows not to handle
old events and if webapp doesn't use new events, old events work
still just fine. And dispatching one extra event really isn't slowing
down anything.
This would be quite similar to what was proposed in
http://lists.w3.org/Archives/Public/public-webapi/2006May/0029.html
That proposal doesn't take account pixel scrolling etc and the
"3)" doesn't handle cancelling z - so I think we could forget "3)"
alltogether for now.
And I think defining one type of wheel might be
good enough - perhaps there isn't need to worry about the old events
which implementations have to support still quite many years anyway.
-Olli
