Hi, Folks-
Ian Hickson wrote (on 4/17/08 3:36 PM):
I'm forwarding this feedback to [email protected] 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!
Ian, thanks for compiling these messages and sending them on; are these
all the emails on the topic, or do these merely represent a sampling of
the mousewheel comments?
I strongly encourage the commentors to post questions directly to the
WebAPI mailing list <[EMAIL PROTECTED]> in order that we can hear
and react quickly to your comments, and make sure they are addressed in
the relevant specification. When they are aggregated in this way, it is
actually much harder to deal with all the issues in a fair manner,
because replies on specific threads can clip out and drown out other
issues, which can get lost in the shuffle. I will try to add the ones
that need follow-up to the issue tracker.
You can see the current list of deliverables for the WebAPI WG on our wiki:
http://www.w3.org/2008/webapps/wiki/Main_Page
Specifically, you can read up on how we're handling DOM3 Events:
http://www.w3.org/2008/webapps/wiki/DOM3Events
And the Mousewheel:
http://www.w3.org/2008/webapps/wiki/Mousewheel
You can also read the spec itself:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
Note that the spec is not quite up to date on the current WG resolution,
but we will be updating it shortly.
Selected replies inline...
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),
Chris,
Sold. This will be handled similarly in DOM3 Events.
some mice support back and forth rocking, and the mouse
wheel click that toggles to 4-way free scrolling.
I suspect that these will actually trigger the relevant key events, not
mouse events per se, but if you can supply more details, we can make
certain of this.
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;
}
}
Erik, we're hoping to have a single Wheel event that unifies these
values and allows for x, y, and z axes (we will also likely specify a
legacy MouseWheel event that covers only a single axis, typically y).
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?
Erik, Dave, let us know if the current proposals don't sync up with that.
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".
Mikko, I don't believe we are specifying it to that level of detail,
relying instead on OS-level user preferences. There are also contextual
differences in wheel behavior, such as page behavior (pixel units) vs.
dropdown behavior (per line units). Olli Pettay raised this issue, and
perhaps we should address this with a contextual indicator or a 'units'
attribute, if th euse case is important enough to warrant it.
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?)
Matthew, we hadn't planned on adding this (Travis Leithead of MS
indicated that they will likely be adding addEventListener instead).
> 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?
We aren't defining 'onfoo' attributes, though a host language could map
them to the equivalent event listener. The current thinking is that we
will state that a host language with attribute-based listeners should do
this.
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...
I think that we will be providing a clean model going forward, and
anticipate that all the major browser vendors will implement it. This
will be a good step forward for authors (though for legacy browsers they
may wish to use a script library that covers those bases).
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...
Erik, we don't anticipate adding @units, but if compelling evidence is
presented, we will consider it.
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. :)
David, see above.
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/
Chris, we don't consider fringe cases like that important...
Seriously, yes, the wheel event is not irrevocably yoked to a scroll
event, though it should be the default action.
For SVG in particular, I think such zooming is an important use case.
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI
