This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Current DOM 'wheel' events only expose bare-minimum data (deltaX, deltaY) that don't fully capture how modern scrollwheels and trackpads behave. Exposing two additional pieces of information would greatly improve the possibilities for interesting and important custom event handling. 1. Inertial-scroll events. For example, on many modern trackpads, "throwing" your fingers results in two distinct phases of scrolling. First, while your fingers are in contact with the trackpad *real* scroll events are delivered corresponding to your finger motion. Second, once your finger(s) leave the surface, a stream of scroll events are *synthesized* corresponding to the velocity of your fingers at the end of phase I. For many applications it is vital to be able to distinguish between *real* and *synthetic* scroll events (e.g. to perform custom scroll handling with different physics parameters or boundary cases, where naive system-provided friction falloff will not suffice). Native event APIs expose this information and I propose that browsers could expose it through new WheelEvent properties. Developers have come up with horrible hacks to work around not having this information (see https://libraries.io/npm/lethargy and weep). 2. Direction-inversion. Users may "invert" the direction of scrolling (conceptually the "page" moves in the same direction as their fingers vs. the "scrollbar" moves 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. Again, 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). If I may humbly propose exposing a few additional properties on delivered DOM wheel events: interface WheelEvent : MouseEvent { ... + readonly attribute boolean isInertialScrolling; + readonly attribute boolean directionInvertedFromDevice; }; inertialScrolling of type boolean, readonly true if the event is the result of a synthetic inertial native scroll event false otherwise directionInvertedFromDevice of type boolean, readonly true if the signs of deltaX and deltaY are reverse the user's physical scrolling direction false otherwise
We should definitely do something here. That said, the UI Events spec tracks bugs and feature requests on GitHub; please file this issue over here: https://github.com/w3c/uievents/issues
Thanks, reposted: https://github.com/w3c/uievents/issues/56