W3C home > Mailing lists > Public > www-style@w3.org > December 2019

Changing delta values on wheel event to be intended scroll distance

From: Clay Martin <clmartin@microsoft.com>
Date: Thu, 5 Dec 2019 00:19:23 +0000
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <MW2PR00MB0364036466C52E38FA606F21C35C0@MW2PR00MB0364.namprd00.prod.outlook.com>

We're modifying how scrolling in Chromium works from being a consistent pixel value to be a percentage of the scrolled-scrollers height. This was how Edge handled scrolling and it leads in most cases to a more consistent scrolling experience (especially on smaller scrollers).

When we first made this change we ran into compatibility issues notably with xtermjs - a widely used javascript-based terminal. They implement custom line-based scrolling. In this case the terminal is phsyically overallped by an element that's listening for the wheel event, but who's scroller is actually the root scroller and not the terminals scroller. Because our implementation is per-scroller, they receive delta values for a scroll event as if it were on the root scroller which is much larger than the terminal scroller's height causing super scrolls (they take the deltaY and compute their own scroll distance based on it).

To mitigate this and other potential compatibility issues we plan to change the deltaX/Y/Z properties returned on the wheel event be the intended scroll distance in pixels rather than the actual scroll distance in pixels and keep it the same value that Chromium returns today (100 pixels). We considered other options like changing the deltaMode to be deltaPage and the value to be a decimal value approximating the percentage scrolled however these were discarded due to compatibility concerns with existing properties.

We wanted to get this audiences thoughts on this change.


Received on Thursday, 5 December 2019 00:33:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:14 UTC