Open foolip opened 7 years ago
@garykac
Usage is high enough that removing wouldn't be straightforward: https://www.chromestatus.com/metrics/feature/timeline/popularity/491 https://www.chromestatus.com/metrics/feature/timeline/popularity/492 https://www.chromestatus.com/metrics/feature/timeline/popularity/493
These numbers may be inflated by event copying patterns (enumeration) though. Still, support in three engines is by itself a strong signal to standardize.
I don't think that they can be standardized. See following document, these attribute values are really different between browsers: https://developer.mozilla.org/en-US/docs/Web/Events/mousewheel#wheelDelta_wheelDeltaX_and_wheelDeltaY_value
That's the reason why Gecko doesn't support them.
Does content depend on these attributes behaving differently in Chrome, Edge and Safari, and do they actually? If those three are well enough aligned, are there additional compat constraints that Gecko would run into if trying to add them?
As a last resort, it's possible to do something like the navigator compatibility mode, but hopefully that shouldn't be necessary.
Does content depend on these attributes behaving differently in Chrome, Edge and Safari, and do they actually?
I don't know, but in my experience, most web apps which handle wheel event directly have bugs with various situations. For example, not supporting high resolution scroll, not supporting page scroll.
If those three are well enough aligned, are there additional compat constraints that Gecko would run into if trying to add them?
It's difficult to say now. The attributes are designed before high resolution scroll, so, I'm not sure if these values can make sense even with modern devices.
The meaning of these attributes are really different in physical or logical level:
IE (I don't know about Edge's behavior), Chrome for Windows, Chrome for Linux, Chrome for macOS with non-continuous wheel device indicate physical amount of turned distance.
On the other hand, Chrome for macOS with continuous wheel device and Safari indicate computed scroll amount which is computed with acceleration, etc.
OK, sounds like we have a bit of a mess. @garykac, do you think this situation can be salvaged? If not, is there any plausible path to removing these attributes?
You mean remove from the browsers? I don't see that happening for backward-compat reasons.
They're already not in the spec because of the issues mentioned above. If we want to fix this issue in the spec, we'd probably need to introduce new attributes that were clearly defined to handle the different meanings currently assigned to wheelDelta*
. We haven't had a lot of push for that however.
Although there's still value in documenting the current (inconsistent) behavior someplace.
Yes, I mean removing from browsers, and I also think that's fairly unlikely to work out.
If it's still possible that picking one behavior and trying to align on that would work out, that would be a good plan A, but failing that, documenting what the options are would be good, I agree.
Apparently in Chrome we have been misinterpreting wheelDelta sign, and nobody complained.
Reposting my anecdote from that bug:
I actually have heard a web developer complaint that sounds like it could be related, from the MDN browser compatibility survey/interviews. One developer had noticed that the scrollIntoView method doesn't work on the horizontal axis in Chrome, and also mentioned a scroll event where the the direction was inverted in Firefox. I'm not certain, but it's plausible that was also about horizontal scrolling and that the inversion of deltaX was the cause.
Does someone have a test case for this?
I was too concise, sorry: the double-negation bug in Chrome affects both wheelDeltaX and wheelDeltaY.
Does this issue also cover the actual mousewheel
event (supported by Chromium and WebKit but not Gecko)?
These three attributes exist in Chromium, EdgeHTML and WebKit, but not in the spec: https://w3c.github.io/uievents/#interface-wheelevent