mousewheel event isn't a standard event. Instead of it, D3E spec defined wheel event which is really different from mousewheel event.
Therefore, I think that only onwheel attribute should be defined by HTML5.
If onmousewheel is used in the wild, bikeshedding the name isn't worth the trouble. Is it used in the wild?
This test shows that Opera and Chrome support only the mousewheel event, not the mouse event. Firefox seems to support neither and I'm not able to test in IE, but juding by http://www.quirksmode.org/dom/events/scroll.html it is supported.
FYI: Firefox has supported D3E wheel event since yesterday, but still not support mousewheel event because it's not in any standard spec.
(In reply to comment #1)
> If onmousewheel is used in the wild, bikeshedding the name isn't worth the
> trouble. Is it used in the wild?
$ grep -aPic "\sonmousewheel\s*=" web200904
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:
Rationale: I concur with Henri, this is used in the wild.
I don't think that onmousewheel is used for D3E WheelEvent. It's used for the legacy mousewheel event on IE, Opera and WebKit browsers. Only IE9 and Fx17 implemented the D3E WheelEvent. Therefore, I don't think the change breaks existing web pages. "onmousewheel" should be available for the legacy (unstandardized) event handler actually, but I think that HTML5 spec shouldn't define such event handler attribute.
So, it's really different event from D3E wheel event (WheelEvent object).
(In reply to comment #6)
> I don't think that onmousewheel is used for D3E WheelEvent. It's used for the
> legacy mousewheel event on IE, Opera and WebKit browsers. Only IE9 and Fx17
> implemented the D3E WheelEvent. Therefore, I don't think the change breaks
> existing web pages. "onmousewheel" should be available for the legacy
> (unstandardized) event handler actually, but I think that HTML5 spec shouldn't
> define such event handler attribute.
Sorry but I'm not entirely certain that I understand what changes you would like to see. Here is what I understand, please tell me if I get it right.
You would like the HTML spec to drop onmousewheel. Reason: At least Firefox doesn't support it and doesn't plan to (according to https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/mousewheel). If that's indeed the case, it seems like a good reason to drop it (requires confirmation though).
Furthermore, you are asking that HTML define the "onwheel" attribute. Am I correctly guessing that by that you mean just the on* attribute but for what it actually does refer to D3E?
(In reply to comment #8)
> You would like the HTML spec to drop onmousewheel. Reason: At least Firefox
> doesn't support it and doesn't plan to (according to
> If that's indeed the case, it seems like a good reason to drop it (requires
> confirmation though).
Yes, but the reason isn't the firefox's plan. The mousehweel event has never defined yet. That's the reason why firefox doesn't have plan to implement it (Actually, the behavior of IE, WebKit and Opera isn't same even on Windows though). I think that HTML5 spec shouldn't define on* attributes whose event isn't defined in any standard spec.
> Furthermore, you are asking that HTML define the "onwheel" attribute.
> Am I
> correctly guessing that by that you mean just the on* attribute but for what it
> actually does refer to D3E?
Sorry, I'm not sure what you ask me here. I just reported only for "onwheel". But it may be better if HTML5 defines on* attributes for all D3E events (e.g., "focusin", "focusout", "mouseenter", "mouseleave", "compositionstart", "compositionupdate", "compositionend", but I'm not sure for deprecated DOM* events in D3E).
Shouldn't it be considered a defect of DOM3 Events if it reinvents the wheel and mints a new event name instead of standardizing what most browsers implement?
(In reply to comment #10)
> Shouldn't it be considered a defect of DOM3 Events if it reinvents the wheel
> and mints a new event name instead of standardizing what most browsers
I don't think so. The mousewheel event isn't useful for web developers since the delta values don't indicate preferred scroll amount. On the other hand, legacy mouse wheel events on Gecko indicate the scroll amount but the behavior is too complicated.
The new D3E wheel event indicates the scroll amount and behaves simply. So, I believe that the D3E wheel event improves everything for mouse wheel event handling on web applications.
I sorted out and documented the legacy mousewheel event's delta value between IE, Opera(Presto), Chrome and Safari. See the chaos of this event. HTML5 shouldn't refer this event. Instead of that, referring D3E wheel event is good solution.
So, I strongly recommend that HTML5 spec should drop onmousewheel attribute and add onwheel attribute.
This is a huge problem. IE9+ implements the `wheel` event but not the `onwheel` attrubute. This makes it impossible for web developers to feature detect the event presence and forcing them to create ugly UA-sniffs, see:
I reported the issue to the IE team:
but they advised to use the flawed `hasFeature` method that isn't even supported any more by Firefox:
This is because feature detection methods based on "I'll tell you if I think I support a particular spec" doesn't work.
Checking for the `on`+event attributes is the most reliable way of feature detecting support for it. If it was specified, I'd have it easier to press IE team to implement it.
WebKit now also always returns true for hasFeature:
(In reply to comment #13)
> Checking for the `on`+event attributes is the most reliable way of feature
> detecting support for it. If it was specified, I'd have it easier to press
> IE team to implement it.
No need to press, it's on our radar--just didn't land in time for IE11.
(In reply to comment #15)
> (In reply to comment #13)
> > Checking for the `on`+event attributes is the most reliable way of feature
> > detecting support for it. If it was specified, I'd have it easier to press
> > IE team to implement it.
> No need to press, it's on our radar--just didn't land in time for IE11.
Good to know, when I reported the issue:
I got a negative answer: that I can use `hasFeature` (which is broken by design).
Too bad you don't plan to make it for IE11, in my `wheel` jQuery plugin I'm first checking for `onwheel` and when missing, I'm doing an ugly UA-sniff by checking `navigator.appName`. The code will now break in IE11 since it changed the `appName` value without matching behavior of other browsers with respect to `onwheel`.
Although the reason why web developers want onwheel attribute for the feature detection is, WebKit and Blink returns non-null for window.WheelEvent even they don't support D3E WheelEvent...
Making this a higher priority to actively seek more feedback on from implementers and webdevs.
Microsoft Edge now supports the `onwheel` attribute as opposed to IE11.
Firefox dropped mousewheel
Ditto for Edge.
Chrome supports both.
So it's time to drop mousewheel imho.
(In reply to Philippe Le Hegaret from comment #21)
Note that Chrome and Edge both added some of the mousewheel's properties onto the Wheel event interface for compat...
[Constructor(DOMString typeArg, optional WheelEventInit eventInitDict)]
interface WheelEvent : MouseEvent
const unsigned long DOM_DELTA_PIXEL = 0x00;
const unsigned long DOM_DELTA_LINE = 0x01;
const unsigned long DOM_DELTA_PAGE = 0x02;
// From Legacy MouseWheel...
readonly attribute long wheelDelta;
readonly attribute long wheelDeltaX;
readonly attribute long wheelDeltaY;
readonly attribute long deltaX;
readonly attribute long deltaY;
readonly attribute long deltaZ;
readonly attribute unsigned long deltaMode;
Re #22 That's something for UI Events to resolve. Do you have a bug for that in UI Events or should I add one? In the meantime, this HTML bug can be closed. PR#13 has been merged.