Expose ticks in wheel events

[garykac]

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23259

Gary Kacmarcik 2013-09-16 21:55:51 UTC

We should consider adding |ticks| to the wheel event.

There are many UX use cases where ticks are more appropriate than pixels, especially considering that pixel values vary from system-to-system (and can vary based on user preferences).

An example of when ticks are more appropriate is with a "digit-selector", a menu or a drop-down list. In each of these cases, a single tick should select the next element regardless of how many "pixels" are reported.

Issues:
What ticks value should be used for input devices that fake scrollwheel events (like a touchpad)? Options are to simply use 0 ticks for these devices, come up with a method for generating fake ticks.

Do we need x, y and z ticks?

Comment 1 Gary Kacmarcik 2013-10-23 13:53:26 UTC

Moving to UI Events

[RByers]

There's a good discussion of the need for this on WICG, based around this use case.

Key question is: how should this API behave on continuous scrolling devices, and can we identify those devices reliably on all OSes? On Windows I think we'd just want ticks to accumulate for every WHEEL_DELTA amount of accumulated delta (see MSDN). But our experience suggests we may not be able to provide an API (like MacOS's hasPreciseScrollingDeltas) which reliably identifies the type of scrolling device on Windows.

/cc @dtapuska @ymalik @teddink

[IvanSanchez]

Related: Leaflet/Leaflet#4592, Leaflet/Leaflet#4538

The current implementations rely on accumulating pixel deltas and using WHEEL_DELTA as a threshold - the main problem being that WHEEL_DELTA is not consistent across browsers (it might depend on the browser vendor, user's configuration and viewport geometry).