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

Mouse wheel feedback

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 17 Apr 2008 19:36:36 +0000 (UTC)
To: public-webapi@w3.org
Cc: WHAT-WG <whatwg@whatwg.org>, Chris Griego <cgriego@gmail.com>, Erik Arvidsson <erik@eae.net>, Dave Hyatt <hyatt@apple.com>, Mikko Rantalainen <mikko.rantalainen@peda.net>, Matthew Raymond <mattraymond@earthlink.net>
Message-ID: <Pine.LNX.4.62.0804171855310.19129@hixie.dreamhostps.com>


I'm forwarding this feedback to public-webapi@w3.org because the mouse 
wheel event stuff is being developed there instead of the WHATWG.

WebAPI WG: Please acknowledge receipt of this feedback and let the people 
below (cc'ed) know how their feedback is handled. Thanks!

On Sat, 18 Jun 2005, Chris Griego wrote:
>
> I've searched through the archives and the specs and have not seen any
> mention of this.
> 
> The mouse wheel as a part of input is now a very handy fact of life
> usually associated only with scrolling up and down, but it has more
> uses than that and I would like to propose that event handling for
> wheel mouse scrolling be added to Web Applications 1.0
> 
> Two real-world uses in today's in desktop applications aside from
> scrolling include the iTunes volume slider, just hover your mose over
> the volume slider and the wheel mouse will increase or decrease the
> volume, and the Mac OS X (10.3+) application switcher (induced with
> alt+tab) where the wheel mouse will scroll through the applications.
> Firefox uses the mouse wheel in scrubbing long menus such as bookmark
> menus.
> 
> The mouse wheel could be put to good use in web applications. One use
> would be within the Google Maps application to freely scrub the map or
> in Opera Show and the S5 slide show system for going to the next and
> previous slides.
> 
> Currently the only way to capture and use the mouse wheel on the web
> is within the Macromedia Flash v7 plugin which added event handling
> for the mouse wheel.
> Flash Documentation:
> http://livedocs.macromedia.com/flash/mx2004/main_7_2/00001481.html
> Example Turotial: http://www.communitymx.com/content/article.cfm?cid=E81CE
> 
> There are things to consider when implementing handling for the mouse
> wheel. You obviously want to handle when the mouse wheel is turned
> upwards or downwards, but you also need to handle the user agent's
> speed preference (1 mouse wheel turn is 3 lines versus 1 line, Flash
> handles this by passing the user agent's preference to the event
> handler), some mice support back and forth rocking, and the mouse
> wheel click that toggles to 4-way free scrolling.

On Tue, 21 Jun 2005, Erik Arvidsson wrote:
>
> Chris Griego wrote:
> > Currently the only way to capture and use the mouse wheel on the web
> > is within the Macromedia Flash v7 plugin which added event handling
> > for the mouse wheel.
> 
> That's incorrect. Both IE (since 5.5?) and Mozilla supports this.
> Unfortunately they do it in different ways.
> 
> IE:
> 
> element.attachEvent("onmousewheel", function () {
>    document.title = window.event.wheelDelta;
> });
> 
> Mozilla:
> 
> element.addEventListener("DOMMouseScroll", function (e) {
>    document.title = e.detail;
> }, true);
> 
> The values here are bit different.
> 
> In Mozilla, if you have set Mozilla to scroll a certain number of rows you get
> the number of steps here. If you have it set to scroll one page at a time you
> get large values and I'm not sure if these represents the number of rows in
> some way.
> 
> In IE it returns multiples of 120 but I guess it really represent 3 rows * 40
> twips/row and that changing this in some control panel applet or in the
> registry might give you other alternative results.
> 
> The values in IE is negative when Mozilla is positive and the other way
> around.
> 
> Here is a pretty simple way to unify these to some extent:
> 
> function getWheelDelta(e) {
>    if (window.event) { // IE
>       return e.wheelDelta / 40;
>    } else {
>       // In case the user has "one screen at a time" we get a
>       // very big value
>       var v = e.detail || 0;
>       if (v > 1000) {
>          v = 3;
>       } else if (v < -1000) {
>          v = -3;
>       }
>       return - v;
>    }
> }

On Mon, 20 Jun 2005, Dave Hyatt wrote:
>
> Safari in the latest Tiger update supports WinIE's mouse wheel system.  We
> also have a wheelDeltaX and wheelDeltaY so that horizontal wheeling can be
> supported.  I had planned to propose this at some point but hadn't gotten
> around to it yet.

On Tue, 21 Jun 2005, Erik Arvidsson wrote:
> 
> This sounds really sweet. How did you define the values for wheelDeltaX 
> and wheelDeltaY?

On Tue, 21 Jun 2005, Mikko Rantalainen wrote:
> 
> To be ready for better pointing devices in the future, I think that the 
> mouse delta should be defined for at least two dimensions (x and y) and 
> the delta should be accompanied with an unit.
> 
> We could define following:
> 
> event.wheelDeltaX: float
> event.wheelDeltaXUnit: "px" | "char" | "page"
> event.wheelDeltaY: float
> event.wheelDeltaYUnit: "px" | "char" | "page"
> 
> And define that positive values mean that content should be positioned inside
> the viewport so that positive deltas bring content to view from bottom and
> from right.
> 
> I assume that in the future, mouse wheels will not have huge discrete steps
> anymore. So moving towards "px" is required. However, the "page" setting will
> be preferred by some and it cannot be cleanly emulated with a single "px"
> value so we need an unit in addition. Also, I selected word "char" instead of
> "row" so that the same unit name is usable with both X and Y axis. I'm not
> sure if "char" unit should be included, though - it can be nicely emulated
> with "px".

On Tue, 21 Jun 2005, Matthew Raymond wrote:
>
> Dave Hyatt wrote:
> > Safari in the latest Tiger update supports WinIE's mouse wheel  system.
> 
>    Mozilla uses addEventListener[1], which is in DOM 2 and DOM 3. (DOM 3 even
> adds addEventListenerNS for different namespaces.) By contrast, IE uses
> attachEvent, which is proprietary and doesn't allow you to specify the the
> initial capture. As a result, I would NOT support using attachEvent in any
> WHATWG standard, especially since it does not appear functionally different
> from addEventListener. (Is there even an IE-proprietary event listener method
> that supports namespaces?)
> 
> > We also have a wheelDeltaX and wheelDeltaY so that
> > horizontal wheeling can be supported.
> 
>    I'm thinking we should define new properties wheelDeltaX and wheelDeltaY
> for MouseEvent. [2]
> 
> > > Chris Griego wrote:
> > > That's incorrect. Both IE (since 5.5?) and Mozilla supports this.
> > > Unfortunately they do it in different ways.
> > > 
> > > IE:
> > > 
> > > element.attachEvent("onmousewheel", function () {
> > >   document.title = window.event.wheelDelta;
> > > });
> > > 
> > > Mozilla:
> > > 
> > > element.addEventListener("DOMMouseScroll", function (e) {
> > >   document.title = e.detail;
> > > }, true);
> 
>    Note that for attachEvent, you name the HTML attribute name and not the
> actual DOM event type. Therefore, in DOM, if you wanted a listener for a
> mousemove, you'd use the string "mousemove" and not "onmousemove". DOM also
> employs the method of using "DOM" at the beginning of strings that don't
> correspond to the associated "on" attributes in HTML 4.01. Since there is no
> official HTML5, this makes Mozilla's implementation above the most standards
> correct.
> 
>    I think I'd prefer something like "mousewheel" or "DOMmousewheel". I'm not
> sure a new |onmousewheel| attribute is called for, though, because there might
> be semantic arguments against it. Anyone have a take on this, by the way?
> 
>    So, I guess I'd like to see this happen:
> 
> | element.addEventListener("mousewheel",
> |   function (e) { document.title = getWheelDelta(e); },
> |   true);
> |
> | function getWheelDelta(e) {
> |   return e.wheelDeltaY;
> | }
> 
> > I had planned to propose this at some point but hadn't gotten
> > around to it yet.
> 
>    I'm hoping you aren't referring to the blatantly nonstandard IE event model
> shown in Chris Griego's IE example...
> 
> [1]
> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget-addEventListener
> [2] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-MouseEvent

On Tue, 21 Jun 2005, Erik Arvidsson wrote:
>
> Mikko Rantalainen wrote:
> > I assume that in the future, mouse wheels will not have huge discrete steps
> > anymore. So moving towards "px" is required. However, the "page" setting
> > will be preferred by some and it cannot be cleanly emulated with a single
> > "px" value so we need an unit in addition. Also, I selected word "char"
> > instead of "row" so that the same unit name is usable with both X and Y
> > axis. I'm not sure if "char" unit should be included, though - it can be
> > nicely emulated with "px".
> 
> It seems "em" describes row better? However, it might be a bit weird due to
> changes in font size depending on where you are in the document. (But I guess
> that is already an issue with scrolling Y rows.)
> 
> If a unit is added it should probably support the other CSS units as well...

On Tue, 21 Jun 2005, David Hyatt wrote:
>
> We actually have not implemented wheelX and wheelY yet... we just did
> wheelDelta.  So the other two are open for specifying. :)

On Mon, 25 Jul 2005, Chris Griego wrote:
> 
> Just to update this thread, Microsoft's new Virtual Earth uses the
> mouse wheel for zooming.
> http://virtualearth.msn.com/

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 17 April 2008 19:48:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 17 April 2008 19:48:25 GMT