Yes - the idea is very aligned with adding
WheelEvents. However, as s developer I wouldn’t know if the
tick is due to a discrete-wheel device, or due to a threshold in a trackpad.
Also, I would like to know whether a
WheelEvent is due to physical interaction on the device, or due to “inertia” scrolling after the user has lifted their fingers.
But still, maybe better for the browser to have a heuristic that’s mostly right, then for every web developer to try to guess?
Browsers have a much better chance at getting the heruistics right - I, as a web dev, would trust a proper implementation of
ticks rather than the heruistics we use now.
So off the top of my head I’d suggest:
firesWheelEvents = true | false (keeping the current nomenclature of
firesWheelTicks = true | false, the browser is sure enough about its heruistics/platform/etc to provide
ticks in a consistent way; if
false, web devs should rather rely on their own heruistics based on pixels/lines).
wheelSubTickResolution = true | false, whether the device can scroll by an amount smaller than one tick (wheeled mice vs trackpads),
firesWheelEvents=false or unknown.
I’m not sure if
InputDeviceCapabilities would be the right place for handling the mismatch between wheel deltas between browsers. For heruistics, it’d be great to know how much pixel delta is expected for a ““normal”” tick - something to tell the 42 pixels from Firefox in linux apart from the 125 pixels on Edge.