W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

Re: Please Review: Mousewheel Event Proposal

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 26 Mar 2008 16:34:20 +0200
Message-ID: <47EA5EEC.90504@helsinki.fi>
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:
(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
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.

Received on Wednesday, 26 March 2008 14:35:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC