Intent to ship: Percent based scrolling.

[Rahul Arakeri]

Contact emails:

ara...@microsoft.com, gerc...@microsoft.com

 

Summary:

This feature changes mouse and  keyboard-initiated scrolls to be interpreted as a percentage of the size of the intended scroller, instead of being translated directly into pixels as they are in Chromium today.

 

Motivation:

As it stands today, when the scroller viewport is only a few hundred pixels tall, each scroll tick will scroll the viewport by a large fraction of the visible content. This is often annoying, as it is more difficult to read or keep track of the material being scrolled. By instead translating each tick into a percentage of the visible bounds, the scroll distance for each tick is appropriate regardless of the size of the scroller.

 

Intent-to-implement:

https://groups.google.com/a/chromium.org/g/blink-dev/c/U3kH6_98BuY/m/uiaeS3D2AwAJ

 

Design doc:

https://docs.google.com/document/d/1LqxCR9xxy962B3Rl1MRmeWTUsMVgY4CtmZSm5plSLwk/edit?usp=sharing

 

Will it be supported on all platforms?

Windows and Linux yes. Mac no. Reason: Mousewheel ticks on Mac don’t animate yet. We’ll revisit this once smooth scrolling for mousewheels on Mac gets enabled.

 

Demo:

1. Go to https://jsfiddle.net/r5esy7bq/show
2. Perform a mousewheel tick and note the delta on the documentElement.scrollTop
3. Relaunch the browser with the feature enabled (--enable-features=PercentBasedScrolling)
4. Redo step 2 and notice that the delta is now a function of the scroller length.

 

Thanks,

Rahul

[Nico Weber]

Repeating my comment from the intent-to-implement:

This sounds more like a UI change than a web platform change. I'm not sure the blink-dev process applies for this?

(I'm pretty sure Chrome's UI here is the way it is intentionally.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB081277C3919B63862E9B9998A6AC9%40CH2PR00MB0812.namprd00.prod.outlook.com.

[Philip Jägenstedt]

If this is purely a UI change that cannot plausibly affect web developers then indeed the Blink launch process is probably not needed for this.

Is that the case? If shipping this amounts to enabling PercentBasedScrolling, then there is code in third_party/blink/renderer/core/scroll/scrollbar.cc which depends on it. Can that code be triggered at all by programmatic scrolling or only via user input?

If this is only a matter of user input, then are there ways that web content could depend on the behavior that would still break sites?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiEuzh2xxJBWz4aCaOXSiVBWGCM410jeEB0yNc9usAaU0A%40mail.gmail.com.

[Steve Kobes]

As bokan@ noted on the intent, this can affect web developers.  So in my opinion the Blink launch process is appropriate.

Chrome's current default of 100px/tick was an "intentional" but not particularly principled choice.  From WebMouseWheelEventBuilder:

      // How many pixels should we scroll per line?  Gecko uses the height of
      // the current line, which means scroll distance changes as you go through
      // the page or go to different pages.  IE 8 is ~60 px/line, although the
      // value seems to vary slightly by page and zoom level.  Also, IE defaults
      // to smooth scrolling while Firefox doesn't, so it can get away with
      // somewhat larger scroll values without feeling as jerky.  Here we use
      // 100 px per three lines (the default scroll amount is three lines per
      // wheel tick). Even though we have smooth scrolling, we don't make this
      // as large as IE because subjectively IE feels like it scrolls farther
      // than you want while reading articles.

This comment dates back to the very early days of Chrome (before multiple rewrites of the smooth scrolling implementation).  I have wished that it could be increased as it makes wheel scrolling feel slower in Chrome than in Edge at typical window sizes on modern displays.  So, I am happy to see this change.

[Chris Harrelson]

What do Gecko and WebKit do? Does WebKit still have the behavior you are proposing to change in Blink? The comment you quoted seems to imply Gecko has similar behavior to Blink today, is that correct?

Are there developer or user complaints about the current behavior that you can link to?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAjAU%3DaOj2J6sQUqZSz-Mu3sfrQnRzUqovFJCo0K%2Bv8U1%3Dj77g%40mail.gmail.com.

[Robert Flack]

Does this affect the deltas in the wheel event sent to Javascript? If so, it may affect things like embedded maps which use the wheel delta amount to programmatically zoom in/out.

[Robert Flack]

I did a few quick tests. It looks like the deltaY in the wheel event is unmodified which means:

• Non scrolling wheel handlers should continue to work as they did before. (e.g. maps, image zooming, etc)
• Custom scrollers which scroll by deltaY / deltaX will not match the native scroll speed.
• Handlers will not know the amount being scrolled by

I think the first case is critical and important not to break. How important are the latter 2 cases? We could support them by adding a new deltaMode for percentage based scrolling and setting deltaY to the percentage scrolled so that the developer knows exactly what's going on. On the other hand, developers may often not check the deltaMode since we have usually returned deltas in pixels so changing the delta risks breaking the first case. Alternately, we could add the new deltaMode but rather than modifying deltaY have an additional field which specifies what the pixel delta is measured out of when converted to a percentage (e.g. on windows we scroll 5% per line where a line is 33px so this seems to be out of 666px). This wouldn't break backwards compatibility and allow developers to match the behavior if desired.

[Rahul Arakeri]

>> It looks like the deltaY in the wheel event is unmodified

@Robert Flack: Just making sure we’re on the same page here. When I tested using a Surface mouse on Windows 10, I saw event.deltaY being reported differently. One tick of the mousewheel reported 150 when the feature was off (i.e the current state) and 100 when it was turned on. Test page: https://jsfiddle.net/cg7vp46n/show

(This corresponds to what I see on Google Maps as well. With the feature off, one mousewheel tick zooms slightly more compared to if the feature was on).

 

PS: Can someone please update the Chrome status as well? I don’t think I have the privileges to do that. Matt, Daniel and Clay are no longer working on scrolling. Please add Me, Olga, Sam and Ben as the owners.

 

Thanks,

Rahul

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TMFK2KexKaue_NZUaTkZS97prszeFHvKnA1JiVjgu%3DVWA%40mail.gmail.com.

[Philip Jägenstedt]

Thanks for testing that and confirming the new behavior, Rahul! It makes sense for deltaY to report the actual size of the scroll increment.

Rob, do you mean that it's important that deltaY keeps returning the same values as before, because sites might have hardcoded them? Using a different deltaMode and reporting percentage values by default seems riskier still, since naive code would interpret it as 5 pixels. Is there a way we can estimate the risk of breakage related to this?

It seems to me that perfectly preserving the behavior of non-scrolling wheel handlers is only possible if we keep reporting the same deltaY and deltaMode and add something new entirely with the true information. That's an option, but one I think we should take only if there's no other way to navigate the web compat problem here.

P.S. I see that the chromestatus.com entry was updated by someone, but I also poked https://github.com/GoogleChrome/chromium-dashboard/issues/1144 about requesting edit access.

[Robert Flack]

On Tue, Jan 19, 2021 at 4:50 AM Philip Jägenstedt <foo...@chromium.org> wrote:

Thanks for testing that and confirming the new behavior, Rahul! It makes sense for deltaY to report the actual size of the scroll increment.

Rob, do you mean that it's important that deltaY keeps returning the same values as before, because sites might have hardcoded them? Using a different deltaMode and reporting percentage values by default seems riskier still, since naive code would interpret it as 5 pixels. Is there a way we can estimate the risk of breakage related to this?

It seems to me that perfectly preserving the behavior of non-scrolling wheel handlers is only possible if we keep reporting the same deltaY and deltaMode and add something new entirely with the true information. That's an option, but one I think we should take only if there's no other way to navigate the web compat problem here.

I have two concerns here:

- One is the compat of existing content which uses the mousewheel to do something other than scrolling (i.e. zooming). The zoom amount on those sites will now be scaled by the size of the nearest ancestor scrolling element. If maps tries to adapt to this they will make zooming on other browsers which haven't adopted this feature zoom by different amounts.

- The other is for sites which know about this and are trying to deal with it. As far as I can tell there is no way to know how much the mousewheel was moved, whether the browser they are running on is scaling it by the size of the viewport, etc. Admittedly the amount of movement before was probably also somewhat arbitrary so perhaps this is just a general feature request for a raw deltaY, as it seems difficult to build a UI which uses the mousewheel for something other than scrolling when the underlying wheel movement information seems to be unattainable.

 

P.S. I see that the chromestatus.com entry was updated by someone, but I also poked https://github.com/GoogleChrome/chromium-dashboard/issues/1144 about requesting edit access.

On Fri, Jan 15, 2021 at 9:29 AM Rahul Arakeri <ara...@microsoft.com> wrote:

>> It looks like the deltaY in the wheel event is unmodified

@Robert Flack: Just making sure we’re on the same page here. When I tested using a Surface mouse on Windows 10, I saw event.deltaY being reported differently. One tick of the mousewheel reported 150 when the feature was off (i.e the current state) and 100 when it was turned on. Test page: https://jsfiddle.net/cg7vp46n/show

(This corresponds to what I see on Google Maps as well. With the feature off, one mousewheel tick zooms slightly more compared to if the feature was on).

Right, the value reported has changed, but it does not seem to match the actual amount scrolled. I was testing on chrome 87 since for some reason I cannot see the flag in chrome://flags on canary to turn it on. I.e. it would report a deltaY of 100 even though the scroll amount would vary based on the height of the scrollport.

[Robert Flack]

I put together a quick demo page to compare the total accumulated deltaY vs the actual scroll distance: https://output.jsbin.com/hakazaz. It seems already the case that the deltaY does not correspond to scroll distance, however with percent based scrolling the amount it is off by varies by window size. I'm not sure if this is justification to not modify the deltaY (since it already does not match the scroll amount) or to expose a raw deltaY.

A related question, should we also create a launch bug for turning this on or is the blink intent sufficient to ship it?

[Rahul Arakeri]

>> I'm not sure if this is justification to not modify the deltaY (since it already does not match the scroll amount) or to expose a raw deltaY.

Rob, just making sure I understand this correctly. Are you suggesting that deltaY should also be a function of the scroller length for percent based scrolling? (i.e, when using DOM_DELTA_PIXEL, should scrollTop == deltaY).

 

I came across something in the spec that says “the value MUST be the measurement along the y-axis (in pixels, lines, or pages)” but doesn’t give a definitive answer for the relationship between the amount scrolled and deltaY.

 

Misc:

Just summarizing how deltaY is currently represented per tick on Windows:

 

	When the OS scroll setting is “Multiple lines at a time”	When the OS scroll setting is “One screen at a time”
Chrome	DOM_DELTA_PIXEL (i.e 33.3 * 3 lines)	DOM_DELTA_PAGE
Edge	DOM_DELTA_PIXEL (i.e 33.3 * 3 lines)	DOM_DELTA_PAGE
Firefox	DOM_DELTA_LINE (i.e 3)	DOM_DELTA_PAGE

[Robert Flack]

I'm confused why using percentage based scrolling should change wheel event deltaY from its prior values if the value it changes it to is neither the amount scrolled nor proportional to the amount scrolled. Changing the deltaY arbitrarily has the potential to break existing sites.

My preference would be that the delta reported is simply how much the wheel has scrolled such that sites using this for zoom are unaffected.

[PhistucK]

Will parallax scrolling effects behave nicely with this change?

I personally find the scrolling pace just fine, I think (well, less so on Mac, but I think it is yet another Apple-is-distinct design decision. That decision also makes smaller scrolling increments not appear to be smooth, surprisingly).

☆PhistucK

--
To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

[Rahul Arakeri]

>> I'm confused why using percentage based scrolling should change wheel event deltaY from its prior values if the value it changes it to is neither the amount scrolled nor proportional to the amount scrolled. Changing the deltaY arbitrarily has the potential to break existing sites.

 

I recently found out some additional information about this that may help to clarify things. It looks like event deltaY is affected by DSF currently (when the feature is off). For eg, on my Surface Laptop, I get event deltaY of 150 per mouse tick at scale 150% and event deltaY of 100 per mouse tick at scale 100%. This apparently is an old bug. With “Percent based scrolling” turned on, event deltaY is not affected by DSF i.e I get event deltaY of 100 (at 150% and 100%) and amount scrolled depends on the scroller length. (See the “Risks” section from Matt’s i2i for more info). I debugged this a bit more and found that this piece of code is responsible for scaling. Also, bokan@ had previously recommended modifying the spec to allow scrolling an amount that is different than what's reported in the wheel event. WDYT?

 

>> My preference would be that the delta reported is simply how much the wheel has scrolled such that sites using this for zoom are unaffected.

I assume you’re talking about the wheel event delta?. For eg: A Surface mouse tick wheel event delta should be 100 (even though the scrollTop is dependent on the scroller length). Did I understand this correctly? If yes, the feature already does that. If I’ve misunderstood, please give me an example to better understand.

 

>> Will parallax scrolling effects behave nicely with this change?

Microsoft Edge stable has had this feature enabled by default for a while now and we haven’t heard any negative feedback around parallax. Visually it looks just fine. If there’s a numerical way to determine that, please let me know.

 

Please let me know if anything is unclear. I’ll be happy to discuss further.

 

Thanks,

Rahul

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_K2T53Z77gFH4B8AV2g-Sz5rDW4HxTn9UbQZPg1Gjweng%40mail.gmail.com.

[PhistucK]

I played with Edge a bit in the last few weeks and I find its scroll pace uncomfortable, to be honest, but maybe I am a vocal minority.

☆PhistucK

[Rahul Arakeri]

When surveying Edge Legacy users on scrolling distance, we found a preference for Edge Legacy’s (percent based) scrolling behavior 75% of the time. Additionally, when this functionality has been broken occasionally in Edge’s Canary builds, users were quick to file negative feedback on it which is an indication that they notice it. Also, since we're proposing to leave the event delta value as-is, this change wouldn't regress any existing sites that use deltaX/Y (and event delta is inconsistent across different DSF anyway). Having said that, we do realize that this largely comes down to user preference as PhistucK@ points out. So please let us know what kind of data would be useful in moving this discussion ahead. We'd be happy to try get that 😊

[David Bokan]

I played with Edge a bit in the last few weeks and I find its scroll pace uncomfortable, to be honest, but maybe I am a vocal minority.

As a counterpoint, I had the opposite experience; Edge felt more snappy and responsive to me. Whether that's percent-based scrolling or the other "personality"-related work like impulse animations I don't know. That said, blink-dev@ is probably best suited to debate the web-compat/interop impact and not the best place to evaluate the UI trade-offs. What's the most appropriate way to get UX owners to weigh in?

My preference would be that the delta reported is simply how much the wheel has scrolled such that sites using this for zoom are unaffected.

I'd +1 this - it means we wouldn't have a compat effect on existing custom wheel event handlers so the risk should be low. That is, the amount of deltaY reported in a wheel event should be unchanged from what is currently reported. I think this technically violates the spec text if we scroll by a different number of pixels but it looks like that already happens commonly (e.g. when using HighDPI device or Ctrl+/- zooming) so maybe just updating the spec would be sufficient?

However, I do have one observation: percent-based scrolling doesn't cause the scroller size to affect the deltaY reported in the wheel event but (at least on Linux) it changes the deltaY from 53 to 100 (according to Rob's demo). Is this intentional? As Rob mentions, it'd be good for this not to affect the reported delta.

[Robert Flack]

On Wed, Jan 27, 2021 at 10:30 PM David Bokan <bo...@google.com> wrote:

I played with Edge a bit in the last few weeks and I find its scroll pace uncomfortable, to be honest, but maybe I am a vocal minority.

As a counterpoint, I had the opposite experience; Edge felt more snappy and responsive to me. Whether that's percent-based scrolling or the other "personality"-related work like impulse animations I don't know. That said, blink-dev@ is probably best suited to debate the web-compat/interop impact and not the best place to evaluate the UI trade-offs. What's the most appropriate way to get UX owners to weigh in?

My preference would be that the delta reported is simply how much the wheel has scrolled such that sites using this for zoom are unaffected.

I'd +1 this - it means we wouldn't have a compat effect on existing custom wheel event handlers so the risk should be low. That is, the amount of deltaY reported in a wheel event should be unchanged from what is currently reported. I think this technically violates the spec text if we scroll by a different number of pixels but it looks like that already happens commonly (e.g. when using HighDPI device or Ctrl+/- zooming) so maybe just updating the spec would be sufficient?

However, I do have one observation: percent-based scrolling doesn't cause the scroller size to affect the deltaY reported in the wheel event but (at least on Linux) it changes the deltaY from 53 to 100 (according to Rob's demo). Is this intentional? As Rob mentions, it'd be good for this not to affect the reported delta.

Rahul, can we ensure that the reported delta is unaffected by this feature so that sites using wheel event listeners are unaffected? I think you also mentioned that you were getting different values on windows (150 vs 100) with this feature enabled vs disabled. Otherwise I think this is good.

[Rahul Arakeri]

Hi David/Rob,

 

Based on my conversation on Slack today with Rob, I’ve prepared a changelist that makes event delta remain unchanged from what is reported currently. This is the current state of things:

• Event delta will have the exact same values irrespective of feature state or DSF.
• Scroll distance is the only thing that will be different after the feature is turned on.

 

So in Rob’s test page, when the feature is turned ON, “Cumulative deltaY” will have the same value as it did when the feature was off and “Cumulative scroll” will be dependent on the scroller length. Please let me know if you have any questions 😊

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TNzxKHYC85nti4CaA-x%3DYT3_%3Dg2R9yA17RzyvSqXM95rw%40mail.gmail.com.

[PhistucK]

Am I missing something? Why would deltaY not reflect the actual delta?

☆PhistucK

[David Bokan]

In percent-based scrolling the scroll distance is determined by the scroller's size - we can't put the actual delta scrolled into the event's deltaY because we don't know which scroller will consume the scroll at the time of the wheel event dispatch. That is, the event will be bubbled up from the DOM target and the scroller that will ultimately consume scroll will depend both on event processing (page's handlers) and current state (can the element scroll? is it fully scrolled?).

Today, deltaY doesn't always match the distance scrolled either; these are bugs related to deviceScaleFactor and page zoom but indicate there shouldn't be any compat issues as a result.

I think it should be ok for event.delta to not precisely match the final distance that will be scrolled. Pages that want to sync something to scrolling would be using onscroll and reading the scrollTop. Pages that override scrolling and perform their own logic using the event.deltaY should be unaffected.

[Philip Jägenstedt]

Thanks Rahul for working through this issue. Continuing to report the old deltaY generally makes sense to me. But while it's already the case that deltaY doesn't match the eventual scroll distance, I wonder if it often matches it, and if after this change it will almost never match?

Is the way to think of deltaY going forward as a legacy "signed constant", where the only information is in the sign? If so, should specs be updated to reflect this?

[PhistucK]

Oh, I see, onwheel is dispatched before the scrolling happens... Yeah, you cannot know.

Thank you!

☆PhistucK

[Rahul Arakeri]

Hi Philip,

 

By “eventual scroll distance”, I assume you meant the “Cumulative scroll” in this test page?

If my assumption is correct then yes you’re right, once the feature is enabled, the eventual scroll distance will almost never match the accumulated deltaY. Given that deltaY (as of today) already doesn’t match the scroll distance (at DSF > 1), I think it does indeed make sense to update the spec and say “event delta should be interpreted as a signed constant”. I’d be happy to do that if we can get consensus on this thread about it.

 

Thanks,

Rahul

[Russell Bicknell]

Hi, as someone that's used the wheel event to build a panning / zooming interface before, I'm against seeing spec text added to ask authors to interpret the deltaX/Y/Z values of wheel events as signed constants. I think that interpretation is only valid in the mistaken case where authors are trying to use it to determine the distance a scrollable area was actually scrolled. (Mistaken due to e.g. possible nested scrollable areas, as pointed out earlier in the thread.)

This value currently seems to represent something like "the distance the user attempted to scroll" and the actual magnitude of this value, regardless of whether or not the container is scrollable or has sufficient remaining scroll distance, is still critical to being able to build any type of continuous input using the mouse wheel / trackpad. While the text is probably a bit too loose as it is now, I think it would be a step in the wrong direction to see the spec changed to imply that using deltaX/Y/Z in this way is either incorrect or deprecated.

-- Russell

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB0812D101907DE764955C6778A6B69%40CH2PR00MB0812.namprd00.prod.outlook.com.

[David Bokan]

> I think it would be a step in the wrong direction to see the spec changed to imply that using deltaX/Y/Z in this way is either incorrect or deprecated.

Just to clarify (or maybe I'm confused and you can help me understand the concern), I don't think that's the proposal. The proposed spec change would mean the delta in the wheel event CAN be a "cannonical" wheel delta for the platform that the browser may, in the end, adjust based on the scroller size. AFAICT the use case you describe wouldn't be affected by this change and the change to the spec would be to allow it rather than mark it incorrect or deprecated.

To make this more concrete: today the wheel delta is a constant based on the platform (e.g. on Linux it's 53px) and is the distance we will scroll. The proposal in this intent is to make it so that the distance scrolled by a wheel tick will be adjusted to scroll by a fixed percentage of the scroller's size but keep 53px as what we would report in wheel.deltaY (which means it may not match the real scrolled distance).

However, the spec text is: "In user agents where the default action of the wheel event is to scroll, the value MUST be the measurement along the y-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled" which means that technically this will not conform to the spec (and there's no way we could because we don't know the value to use at the time the wheel  event is dispatched). Would changing the text to "SHOULD", or allowing a "platform-defined scroll distance" in cases the browser doesn't know affect the use case you describe?

[Ben Mathwig]

This is just me thinking out loud, but does it make sense for the delta values to be determined by scroller size?

tl;dr I think the spec change should set delta values to be a unit-less passthrough from the platform event itself rather than set either by scroll distance calculation or a fixed value based on platform. It would remove the confusion about how that value relates to scroll distance and the numbers would be relatively close to what they are now for backwards compatibility.

Here are some things to consider:

• A user can adjust scroll speed settings in the hardware vendor control panel for their specific mouse. The WM_MOUSEWHEEL event entering the Chromium message pump can have a different value for GET_WHEEL_DELTA_WPARAM depending on the hardware vendor’s driver sending a smaller or larger value in that parameter slot.
• By default, Windows sets the constant WHEEL_DELTA to 120 to represent “one increment”. Typically an application will accumulate messages until that constant is hit to trigger a scroll event, but some applications may do more granular scrolling.
• As Russell commented, sometimes developers want to use that value to either (a) determine that a wheel has “ticked” or (b) figure out the magnitude of the event to zoom or pan accordingly.

Perhaps the updated language of the spec should change the units that the deltas are measured in. Instead of pixels, the value is unit-less and is a passthrough of the event parameter from the platform and a new constant exposed to contain the platform value for “one increment”. Here’s how that might look on Windows:

• WM_MOUSEWHEEL is dispatched to the application.
• Actual event delta value is extracted from the WPARAM. Value is based on hardware vendor driver settings, or configuration of those settings by the user.
• Example event delta is [60] (the user is using a no-notch smooth scrolling mouse wheel and only moved it a little.
• WheelEvent.deltaY is set to value [60] and in the case of Windows, WheelEvent.WHEEL_DELTA is set to [120].
• A developer who is listening to the event in Javascript can use the WheelEvent.deltaY and WheelEvent.WHEEL_DELTA to determine what to do for their specific application (ie. Half zoom, half pan, etc.)
• Chromium scroller code determines that the user scrolled half a platform increment ([60] / WHEEL_DELTA [120] for Widows) and with percent-based scrolling computes a pixel scroll amount using the nearest scrollable container.

I think this would ensure compatibility with existing applications that use the event and clear up any confusion in the spec around how that value (pixels/lines/pages) relates to scrolling distance. It disconnects the delta values from actual scroll distance, fixing the discrepancy that has been mentioned earlier. It also opens up the possibility of allowing the user to have fine grain controls over their scrolling experience where a “one size fits all” may not be preferable to them. I also wonder if this fixed value is contributing to some user reports related to their mouse scrolling too quickly, if the actual wheel delta at the platform level isn’t being interpreted correctly.

[Russell Bicknell]

Is this I2S intended to *only* affect inputs from devices that scroll in discrete steps? If so, I think not realizing that earlier might have confused me a bit. I agree that the deltas shouldn't be required by the spec to be the distance that the browser actually scrolls some element (if any) in response to input that produced a wheel event: it can't do this if the element that should be scrolled doesn't have enough remaining distance or if there isn't an appropriate element to scroll in response. My main concern is that the spec shouldn't imply that the magnitude of wheel events' deltas aren't meaningful or aren't related to the coordinate space of the viewport.

I also don't think that the spec should be changed to say that the deltas are unitless because this wouldn't be backwards compatible with existing pages if the platform's WHEEL_DELTA ever changes or between platforms with different WHEEL_DELTA values, since you still have to pick some scale factor to convert into pixels.[1] However, having a constant that lets you convert between the deltas and their equivalent in discrete ticks still sounds nice: `deltaY / WHEEL_DELTA` could still produce the number of discrete ticks, but deltaY is in pixels and WHEEL_DELTA is pixels / tick (rather than unitless and 1 / tick).

Ideally, I think the spec would try say something along these lines to compute a wheel event's deltas: if there were a single element with infinite overflow in both directions that would be scrolled by the browser in response to that event not being cancelled, the deltas for that event should match the change in the scrollTop/scrollLeft that the browser would apply to that hypothetical element. I'm not a spec editor, so I don't know how to phrase that in a formal way[2] but what I'm getting at is that wheel events' deltas' units should be CSS pixels and the magnitude and direction should match what the browser would do if a single element could consume the entire scroll distance change 'intended' by the event.

Though, if the spec just said that, then I think the feature proposed in the I2S would imply changing the actual event deltas also, which has been talked about earlier in this thread. I guess this could be worked around by saying the hypothetical element has a particular size that might be related to the viewport, but that feels weirdly specific loophole.

Personally, I can't really tell if I would or wouldn't like the change in the scroll behavior that this I2S intends, but that's subjective and I really only care about making sure the spec doesn't prevent page authors from emulating their users' platforms' native scroll behaviors, momentum and velocity included. If Chrome were to multiply the deltas in a wheel event by some factor before it takes the default response of scrolling an element itself, maybe I'll be a bit annoyed (maybe not?), but ultimately this doesn't seem like it would have to be backwards-incompatible or break the spec behavior I was trying to state above, but I'm not sure how to actually phrase that such that it doesn't imply disconnecting the deltas from CSS pixels (main opposition) or changing the deltas depending on the element's size (seems weird and maybe has back-compat implications, but maybe more correct if that's what Chrome's size-dependent-scroll-behavior does?).

-- Russell

[1]: Having to detect the platform and provide a potentially different value for each would not be great.
[2]: Particularly for deltaZ, given the web has no concept of z-axis overflow. Anyone want to specify `scrollFront`? :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c5a2de59-64c1-4420-860e-5f3a25e37de5n%40chromium.org.

[Mike West]

I've read through this thread again, and it's unfortunately not clear to me whether this change is actually directly web-facing, or is only user-facing (except insofar as the page would see itself being scrolled to a different point after the user scrolled). Are we going to end up in a place where the deltas visible to the page on each event are different? Or will events be fired in a different order/different time?

I'm trying to figure out what's going to be different for web developers as a result of this intent. If the impact is really user-facing, then I think we'd end up considering this an embedder's choice, and not something that requires API owner input. If there are developer-facing impacts, we'd come to a different conclusion.

Help?

-mike

[Mike West]

Friendly ping on the question of what's actually web-exposed here. :)

-mike

[Rahul Arakeri]

Hi Mike,

 

Apologies for the late response. I got sidetracked with another project. By “web-facing” I assume you meant to ask if this feature would affect websites that rely on DOM properties like scrollTop? If I’ve understood your question correctly, yes, this feature does indeed affect such websites since scrollTop (and the visual scroll distance) would be based on the scroller length once the feature is turned ON. For sites like Google Maps which I believe use the scrollwheel event.deltaY to zoom in/out, there would be no difference since event delta would be unaffected.

 

This feature is currently behind a flag named “Percent based scrolling” which should be available via about:flags so please feel free to try it out on this test page. Please let me know if I’ve misunderstood anything.

 

Thanks,

Rahul

[David Bokan]

From what I can tell trying https://output.jsbin.com/hakazaz, the only change now with percent-based scrolling is the actual distance scrolled; the deltas reported in the wheel events are unchanged so I believe this change to be low risk in terms of compatibility and interop and shouldn't affect authors.

[Chris Harrelson]

Based on this compatibility analysis, LGTM1 to ship!

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BN6QZs66dOURmSaxpFrtv1twxf9ZN0twhCm5uNpUvzwBKKycQ%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVa_go0b7LmYSLr87vLb1MeO12%2BLSFUVqBHCho0%3Dgymeg%40mail.gmail.com.