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

RE: Proposal for mousewheel events

From: Doug Schepers <doug@schepers.cc>
Date: Mon, 10 Apr 2006 04:46:26 -0400
To: "'Web APIs WG (public)'" <public-webapi@w3.org>
Message-Id: <20060410084631.33AD360B8B@filch.dreamhost.com>


Ian Hickson wrote:
| I propose that we use "mousewheel" for vertical movement and 
| "mousewheelx" for horizontal movement, both using the 
| same interface (which would be compatible with IE's implementation).

I have deep reservations with the idea of separating out the vertical and
horizontal wheel events, as opposed to having a single event that has both
vertical and horizontal properties.

On the one hand, I do like the idea of being able to capture or cancel them

On the other, I am concerned that the synchronization of diagonal movement
will be extremely hard to manage in script in a situation where the author
wants to capture both as part of the same event. Can someone describe how
this could easily be done with this proposal? It seems easier to set the
value of one or the other to 0, if cancelling them is desired, than it would
be to join together 2 separate events.

I also wonder if the issue of wheel events can be adequately addressed
without some resolution on multiple input devices? I think that for mobile
devices in particular, you are likely to see several wheel inputs. How will
"mousewheel/mousewheelx" lend themselves to such devices?

A few inline comments to previous posts on this thread:

Anne van Kesteren wrote:
| I support this proposal. Although the names are not really desirable

That's an understatement. 

| having two completely different names, like mousewheel and  
| horizontalwheel, is worse. This is at least consistent and 
| builds upon what developers already know and use.

I am of the informed opinion that developers are capable of learning new

| As opposed to having a single  event, this allows  
| cancelling horizontal _or_ vertical scrolling.

I know that Anne knows this, but I want to make sure that we do not conflate
the idea of the wheel event with scrolling. 

Three other common uses for the wheel:
1) sequential selection, as in a listbox or dropdown (note that these do not
have to take the typical vertical widget layout, but might be horizontal or
arranged in a ring), which is different than merely scrolling;
2) font-size increase/decrease (typically in conjunction with a key-press);
3) zooming in or out (as in an SVG canvas, or on a raster).

Other uses creative authors might want to have this for:
4) focused slider widget control (alters value/position of widget, not
change of selection or scrolling);
5) audio volume control (may be on a non-visible widget);
6) animation/video playback time control (like a jogwheel on an editing
7) precision tweaking of a handle's position (as on a drawing app... much
finer control than mouse movement).

We don't need to have an exhaustive list... suffice it to say that to assume
that the wheel only scrolls may lead us to underspecify it, or specify it

Ian Hickson wrote:
| Why not just do:
|    interface MouseWheelEvent: MouseEvent {
|      readonly attribute long wheelDelta;
|    }
| ...where |wheelDelta| is a multiple of 120 (positive means 
| rotated away from user or to the right, negative means 
| rotated towards user or to the left), and we set |detail| 
| to wheelDelta divided by 120? 

I think this sounds pretty reasonable.

| Backwards compatible with IE and Safari (and thus with existing content),
| sensible at the same time.

I'd be very curious to find out how much content out there uses the wheel,
and how much of that is compatible with other content (that is, is there
competing content out there)?  I certainly don't want to break content
needlessly, but neither do I want to artifically reduce the options for
future content (which will greatly outnumber current content). It would be
nice to base our decision from an informed position.

| (Issue: In an RTL environment, should it be right/left as well or 
| left/right instead? I suggest raising this with i18n.)

I would be very surprised if that were the case, but better safe than sorry.

I also suggest raising this design with WAI to make certain that we aren't
overlooking use cases there. I have the feeling that for certain users with
limited mobility, the wheel might be more important than the pointer device
for particular tasks.


www.vectoreal.com ...for scalable solutions.
Received on Monday, 10 April 2006 08:46:42 UTC

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