- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 17 Apr 2008 16:44:54 -0400
- To: public-webapi@w3.org
Hi, Folks-
Ian Hickson wrote (on 4/17/08 3:36 PM):
>
> 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!
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 <public-webapi@w3c.org> 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
Received on Thursday, 17 April 2008 20:45:27 UTC