Re: [uievents] Expose 'direction-inversion' in wheel events (#57)

> 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.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/57#issuecomment-171471648