w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
145 stars 52 forks source link

Add WheelEvent#wheelDelta/wheelDeltaX/wheelDeltaY #138

Open foolip opened 7 years ago

foolip commented 7 years ago

These three attributes exist in Chromium, EdgeHTML and WebKit, but not in the spec: https://w3c.github.io/uievents/#interface-wheelevent

foolip commented 7 years ago

@garykac

foolip commented 7 years ago

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.

masayuki-nakano commented 7 years ago

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.

foolip commented 7 years ago

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.

masayuki-nakano commented 7 years ago

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.

foolip commented 7 years ago

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?

garykac commented 7 years ago

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.

foolip commented 7 years ago

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.

mustaqahmed commented 4 years ago

Apparently in Chrome we have been misinterpreting wheelDelta sign, and nobody complained.

foolip commented 4 years ago

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.

foolip commented 4 years ago

Does someone have a test case for this?

mustaqahmed commented 4 years ago

I was too concise, sorry: the double-negation bug in Chrome affects both wheelDeltaX and wheelDeltaY.

zcorpan commented 2 years ago

Does this issue also cover the actual mousewheel event (supported by Chromium and WebKit but not Gecko)?