Expose 'direction-inversion' in wheel events

[lorenbrichter]

Split from #56

Current DOM 'wheel' events only expose bare-minimum data (deltaX, deltaY) that don't fully capture how modern scrollwheels and trackpads behave. Exposing additional bits of information would greatly improve the possibilities for interesting and important custom event handling.

Users may "invert" the direction of scrolling (conceptually the "page" moving in the same direction as their fingers vs. the "scrollbar" moving in the same direction as their fingers). Unfortunately this setting is not exposed to developers, and it would be useful to know whether given scroll deltas mirrored the users real-world finger motion.

Native APIs expose this information, and it would be extremely useful to have access to it in the browser in cases where scrolling gestures are interpreted as something other than 2D scrolling, (3D navigation for example).

I propose exposing an additional property on delivered DOM wheel events:

interface WheelEvent : MouseEvent {
...
+    readonly    attribute boolean       directionInvertedFromDevice;
};

directionInvertedFromDevice of type boolean, readonly
  true if the signs of deltaX and deltaY are reverse the user's physical scrolling direction
  false otherwise

[RByers]

I agree this is worth doing and should be relatively straight forward. We'd probably implement this in blink if other vendors were interested too. One scenario where this can be really valuable is when using wheel events to drag an element around the screen. When I built this demo for that, I had to provide an option for the user to invert the vertical direction.

[masayuki-nakano]

How to implement this on Windows? At least Synaptics's touchpad, it has "invert scrolling direction" feature in its option. However, of course, it causes inverted WM_MOUSEWHEEL events. So, applications cannot detect the information. Even if browsers read its registry, browsers cannot distinguish if received WM_MOUSEWHEEL message came from Synaptics's device.

I'm afraid that browsers provide different UX/behavior to Windows users and Mac users for same operation with similar device. It must make web application providers confused especially when they document the behavior in the manual or something.

[lorenbrichter]

Interesting. Perhaps if it's indeterminate on the platform the property could simply be undefined. I think it's worth thinking about consistency from the perspective of a single person as well (whom we can usually assume is sitting in front of a single computer running a single operating system). If (for example) Mac apps behave in a certain way with regard to scroll events, I think it's reasonable to expect web pages on the same platform to behave in a similar way.

(Also, sounds like a good excuse for Windows to add that data to its mouse wheel messages, they seem to care a lot more about this recently with their precision touchpad work).

[RByers]

I agree we wouldn't want to have this feature if it would be a lie on some platforms. Having an unknown value for platforms where it's not (currently) supported seems reasonable, especially if there is interest in someday exposing such a thing on that platform. Eg. For Windows it's probably fine to consider all vendor-specific touchpads as legacy and ask only if this can be implemented on Win10 for high precision touchpads. @jacobrossi, thoughts?

[RByers]

If we don't want to clutter WheelEvent with this, it may make sense to put on InputDeviceCapabilities instead. I think the semantics and outcome would be identical.

[jacobrossi]

Users may "invert" the direction of scrolling (conceptually the "page" moving in the same direction as their fingers vs. the "scrollbar" moving in the same direction as their fingers). Unfortunately this setting is not exposed to developers, and it would be useful to know whether given scroll deltas mirrored the users real-world finger motion.

Native APIs expose this information, and it would be extremely useful to have access to it in the browser in cases where scrolling gestures are interpreted as something other than 2D scrolling, (3D navigation for example).

As mentioned, I don't believe this information is exposed on the standard Windows APIs. Proprietary touchpad vendors may expose this otherwise, but that will lead to variations across devices, which is bad. I imagine the intent is for this to be something the user is in control of. The user decides which way is "up" and the application isn't given the opportunity to re-invert that so that user experience is consistent across all applications.

One scenario where this can be really valuable is when using wheel events to drag an element around the screen. When I built this demo for that, I had to provide an option for the user to invert the vertical direction.

I'm not sure I've ever seen wheel / 2-finger scroll used for a dragging behavior. Typically you want free-motion for drag and drop, which would be a one finger (non-wheel) interaction, right? This doesn't sound like a scenario to optimize for IMO.

I agree we wouldn't want to have this feature if it would be a lie on some
platforms.

Agreed.

For Windows it's probably fine to consider all vendor-specific touchpads as legacy and ask
only if this can be implemented on Win10 for high precision touchpads.

There are a lot of non-PTP devices out there (perhaps more than there are PTPs? idk). So I wouldn't be in favor of this inconsistency across devices.

If we don't want to clutter WheelEvent with this, it may make sense to put on InputDeviceCapabilities instead. I think the semantics and outcome would be identical.
It sounds pretty specific to wheels, so I wouldn't want to put it on an interface that is used in many other places. But, I'm not yet convinced in the purpose of this property or, at least, it's ability to be implemented across platforms and devices reliably.

[jacobrossi]

Tagging in @teddink for his thoughts

[RByers]

I agree it's important to make sure this API doesn't need to lie. But at the same time, I'd hate to hold back the experience on the web on some devices due to design limitations of just one OS ;-). Would a tri-state property (maybe true, false and undefined) address your concern here?

Then again, if the only people who will really ever benefit from this API are MacOS, ChromeOS and Linux users, then that makes it pretty low priority for me (in terms of impact).

[jacobrossi]

But at the same time, I'd hate to hold back the experience on the web on some devices due to design limitations of just one OS ;-). Would a tri-state property (maybe true , false and undefined ) address your concern here?

Are there examples of this property being used outside the web that we think are valuable? I haven't seen any examples that amount to "holding back the web" aside from your dragging one, which I'm not sure is practical for users or desired by developers. E.g. what's the native app that can't come to the web because of this?

[RByers]

I don't know offhand where Mac apps are using this today, but I'm sure I can find examples if it would help. One use case I was just looking at is the volume slider in YouTube. It's incredibly un-intuitive that swiping right on my touchpad makes the volume slider move left, but when I have "invert direction" turned off it feels like a nice feature.

[jacobrossi]

Huh, I'd say it's incredibly un-intuitive that the two-finger swipe controls volume in this context -- I wonder if that was deliberate design on YouTube's part or if they'd actually prefer it do nothing. Tap + drag seems what's desirable here.

[RByers]

They tell me it's deliberate, but it sounds like they're re-evaluating the decision (in case you haven't guessed, this is coming up in the context of passive wheel listeners - YouTube's use of wheel listeners can have a big impact on scroll perf for us today.

[lorenbrichter]

@jacobrossi: I agree that inconsistency across devices isn't great, but I'd argue that inconsistency within a single device is even worse (think: a single person experiencing different behavior between a native app vs. the web). And the vast majority of users are going to be feeling inconsistencies of that sort. There are already plenty of cross-platform inconsistencies that are considered "good" since they embrace native conventions (e.g. differences in text rasterization).

An example close to my heart, try http://onshape.com/ on a Mac without a mouse. 3D navigation is currently extremely unergonomic. While they can (and plan to) improve click-less trackpad orbit/pan support, it will be impossible for them to do so in a way that would be on-par with native CAD apps on the platform (say, where 3D orbit gestures were mapped to the direction of a user's fingers).

(See https://forum.onshape.com/discussion/comment/12119 )

@RByers: putting the data on InputDeviceCapabilities makes a ton of sense.

[foolip]

FWIW, the precedent for when the value can be unavailable is nullable attributes, like on DeviceOrientationEvent and friends. So true, false, null, in that case.

[VeXell]

New version of windows also support change scroll direction and safari can provide this information on macOs with webkitDirectionInvertedFromDevice. Do we have any chance if it would be implemented ?

[devongovett]

This would be useful for implementing number fields or other incrementable/decrementable value fields where scrolling over them increments/decrements the value. Ideally this would not be affected by natural scroll settings, so some way of knowing to flip the delta would be great.

[jtran]

I don't know offhand where Mac apps are using this today, but I'm sure I can find examples if it would help.

The Apple Maps macOS app uses Shift + scroll gesture to zoom in and out. Pushing away always zooms in, regardless of the natural scroll direction setting. I'd like to mimic this in my app, but it's impossible without this API.

[brandonmcconnell]

Is anyone actively working on this? Anything we can do to help push this forward? Especially today, where many devices support enabling "natural" scroll direction with/without touch, I was surprised to find this wasn't already natively supported.

Happy to help in any way I can 😃