- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 26 Mar 2008 16:34:20 +0200
- To: "Web APIs WG (public)" <public-webapi@w3.org>
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
Received on Wednesday, 26 March 2008 14:35:05 UTC