- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 18 Mar 2008 22:24:25 -0400
- To: Web API public <public-webapi@w3.org>
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