Intent to Ship: Respect overscroll-behavior on non-scrollable scroll containers

42 views
Skip to first unread message

Robert Flack

unread,
Sep 11, 2025, 4:06:39 PM (11 hours ago) Sep 11
to blink-dev

Contact emails

fla...@chromium.orgperry...@gmail.com

Specification

https://www.w3.org/TR/css-overscroll-1/#propdef-overscroll-behavior

Summary

The overscroll-behavior applies to all scroll container elements, regardless of whether those elements currently have overflowing content or are user scrollable. Developers can use overscroll-behavior to prevent scroll propagation on an `overflow: hidden` backdrop or an `overflow: auto` element without needing to consider whether it will currently be overflowing.



Blink component

Blink>Scroll

Web Feature ID

overscroll-behavior

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

This should be implemented on other browsers as well, as it matches the specification. However, until this happens there are compatibility risks that some sites may over accidentally set overscroll-behavior on elements which don't currently apply today (either overflow: auto or not having overflow) and will start applying, or that developers will rely on this behavior and have accidental scroll chaining in other browsers until they implement it as well. This change will affect a large number of sites per https://chromestatus.com/metrics/feature/timeline/popularity/5596. I have done compat analysis of many of the top sites affected by this in https://issues.chromium.org/issues/41371072#comment45 and found it to either not have a meaningful impact or to better honor the developer specified intent.



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics

This improves the ergonomics of overscroll-behavior, fixing the current unpredictable layout dependent behavior we have today.



Activation

It may be difficult for developers to take advantage of this fix before it is adopted in other browsers as it is likely not possible to feature detect. They could remove pre-existing hacks to get this functionality (i.e. ensuring 1px overflow) on supporting chromium browsers.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

None



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/css/css-overscroll-behavior/overscroll-behavior-without-overflow.html?label=experimental&label=master&aligned



Flag name on about://flags

None

Finch feature name

OverscrollBehaviorRespectedOnAllScrollContainers

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Measurement

The OverscrollBehaviorOnNonScrollableScrollContainer feature counter measures how often this new behavior is or would be triggered. https://chromestatus.com/metrics/feature/timeline/popularity/5596

Sample links


https://ebidel.github.io/demos/chatbox.html
https://codepen.io/rctneil/pen/rJYONj

Estimated milestones

No milestones specified



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5129635997941760?gate=5124735842910208

Robert Flack

unread,
Sep 11, 2025, 4:13:54 PM (11 hours ago) Sep 11
to blink-dev
Note that this is a repost of https://groups.google.com/a/chromium.org/g/blink-dev/c/p2edIq4J-eQ/m/5MxPnuT8AwAJ as an I2S instead of PSA as I am seeking and will await LGTMs considering the potential compat risk.

On the associated bug I have looked at a sampling of 10 popular sites affected by the overscroll-behavior change on httparchive and found it to either not impact them or be beneficial:
1. https://lichess.org/ On smaller screens the `#topnav` element opens in a menu. The application of overscroll behavior seems to be there to prevent scrolling the content and so this site will be improved by the change.
2. https://cardgames.io/ Seems to just be the body element that has overscrollBehavior set. This shouldn't be affected.
3. https://open.spotify.com/ The body and "your library" panel fit into this case. I think this change would apply the intended behavior as they do not seem to intend for the scroll to propagate.
4. https://www.accuweather.com/ Only the body has overscroll behavior specified.
5. https://www.ikea.com/ Their mobile menu `#top-mobile-menu` has overscroll-behavior on it. This is presumably to prevent accidental pull to refresh while scrolling through the menu and would be fixed by this change.
6. https://www.tiktok.com/explore The side nav has contain overscroll-behavior. With this change you would no longer be able to scroll the main page by scrolling on top of the sidebar. This seems to be the intention but is not currently being honored.
7. https://x.com/ Only the root element seems to have overscroll-behavior defined.
8. https://store.epicgames.com/ I'm unable to find the affected element
9. https://www.airbnb.com/ There are several scrolling containers with overscroll-behavior defined however I think these are only "not scrollable" while the page is loading. By the time the user interacts with them they have scrollable overflow and so are unaffected. The usage also seems to indicate they would not want scroll to chain past those containers.
10. https://www.expedia.com/ I'm not able to find where the property is used.

In terms of developer demand, there are many bugs that have been duped into https://issues.chromium.org/issues/41371072 all concerned that the incorrect behavior currently implemented in all browsers prevents using it for the intended purposes. In particular, developers want to be able to use overscroll-behavior without the unpredictability of whether it applies depending on the layout of their scrolling content.

Common uses for this include,
1. Preventing scrolling in inner widgets from chaining to document scrolls
2. Preventing scrolling on a dialog covering the page from chaining to and scrolling the page
3. Preventing scrolling on a menu  from chaining to and scrolling the page.

Right now, authors have to carefully ensure that they have overflow: auto and some scrolling content and then presumably hide the scrollbar in cases where they are only adding overflow: auto; to allow overscroll-behavior to apply.

Chris Harrelson

unread,
Sep 11, 2025, 5:47:12 PM (9 hours ago) Sep 11
to Robert Flack, blink-dev
On Thu, Sep 11, 2025 at 1:06 PM Robert Flack <fla...@chromium.org> wrote:

Contact emails

fla...@chromium.orgperry...@gmail.com

Specification

https://www.w3.org/TR/css-overscroll-1/#propdef-overscroll-behavior

Summary

The overscroll-behavior applies to all scroll container elements, regardless of whether those elements currently have overflowing content or are user scrollable. Developers can use overscroll-behavior to prevent scroll propagation on an `overflow: hidden` backdrop or an `overflow: auto` element without needing to consider whether it will currently be overflowing.



Blink component

Blink>Scroll

Web Feature ID

overscroll-behavior

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

This should be implemented on other browsers as well, as it matches the specification. However, until this happens there are compatibility risks that some sites may over accidentally set overscroll-behavior on elements which don't currently apply today (either overflow: auto or not having overflow) and will start applying, or that developers will rely on this behavior and have accidental scroll chaining in other browsers until they implement it as well. This change will affect a large number of sites per https://chromestatus.com/metrics/feature/timeline/popularity/5596. I have done compat analysis of many of the top sites affected by this in https://issues.chromium.org/issues/41371072#comment45 and found it to either not have a meaningful impact or to better honor the developer specified intent.



Gecko: No signal

WebKit: No signal

Could you file for standards positions as well?
 

Web developers: No signals

There is evidence of developer demand for what you're planning to ship, right?
 
--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TOXh63zS2ZaZBqsMo0v7%3DoFZQMv1phEVv8pLe%3D%3Dob9-pQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages