As a web application developer brought here from https://github.com/whatwg/html/issues/7732, I would love to see this. I would be able to eliminate a lot of JavaScript from what's served, particularly from a library (https://www.npmjs.com/package/body-scroll-lock) that tries to emulate this behavior.
On Tuesday, October 7, 2025 at 2:06:47 PM UTC-4 Bruno Stasse wrote: > Web developer and library author (silkhq.com) dealing with scrolling > substantially here. > > One risk of breakage with this change is patterns like carousels applying > `overscroll-behavior: contain | none` on both axis to prevent the "swipe to > go back" behavior in most desktop browsers, which didn't capture scrolling > on the vertical axis so far, but will now, thus preventing page scrolling. > I have looked for such pattern and could only find carousels properly using > `overscroll-behavior-x: contain | none`, but I suspect there are such cases > in the wild. > > That being said, this change would be very useful in many cases, as > mentioned in the thread, so it may be worth breaking some stuff to fix > others and match the spec. > > Le vendredi 19 septembre 2025 à 22:27:37 UTC+2, Zouhir Chahoud a écrit : > >> from a Web author perspective, it's quite common that we *attempt* to >> lock scrolling on the document's scrolling element when certain side-panels >> or overlays are rendered. >> >> With this proposal, instead of managing overflow on scrolling elements >> with javascript at application level, the side-panel or overlay can -at >> local level- specify the desired scroll chaining behavior with a 1 line of >> CSS and without needing to know if content can scroll or not. Definitely a >> great improvement. >> >> On Wednesday, September 17, 2025 at 9:41:11 AM UTC-7 Mike Taylor wrote: >> >>> LGTM3 >>> On 9/17/25 11:36 a.m., Daniel Bratell wrote: >>> >>> LGTM2 for the plan Philip outlined below. >>> >>> /Daniel >>> On 2025-09-17 17:28, Philip Jägenstedt wrote: >>> >>> We discussed this at the API owners meeting today. (Present: Daniel, >>> Yoav, Alex, Chris, Mike, Dan, Vlad, me.) >>> >>> LGTM1 >>> >>> Based on the use counter (8%) and the number of sites checked (10) we >>> don't have high confidence that this won't break something. However, we >>> also don't have a concrete way to further reduce the uncertainty beyond >>> manually checking hundreds of sites and making a judgment call about >>> whether each is improved or not, which does not feel reasonable. >>> >>> Instead, to shake out as much breakage as we can, we'd like to let this >>> bake at 100% on beta for ~4 weeks (one extra milestone) and monitor for >>> bugs. If there's nothing concerning, then launch at 100% on stable, while >>> being prepared to revert if there are reports at that point. >>> >>> If you could report back here before going to stable that would be >>> great, but no further approvals needed if things are looking good. >>> >>> On Wed, Sep 17, 2025 at 5:11 PM Alex Russell <[email protected]> >>> wrote: >>> >>>> Thanks. I'm pinging people. Hopefully folks can weigh in here quickly. >>>> >>>> On Tuesday, September 16, 2025 at 7:11:54 AM UTC-7 Robert Flack wrote: >>>> >>>>> I completely agree, the point here isn't to follow the spec. The >>>>> reason I think we should follow the spec in this case is that it is more >>>>> ergonomic and predictable when applying overscroll-behavior doesn't just >>>>> work sometimes. I think that developers are rightfully confused by those >>>>> cases where it doesn't work which is why we have had several bugs filed >>>>> about it. >>>>> >>>>> I have reached out to a few web developers. If you know anyone who >>>>> might have thoughts on this please loop them in as well. >>>>> >>>>> On Mon, Sep 15, 2025 at 2:00 PM Alex Russell <[email protected]> >>>>> wrote: >>>>> >>>>>> I'd love for web developers who have been paying close attention to >>>>>> scroll behaviour to weigh in here. This has been a deep well of sadness >>>>>> in >>>>>> a cross-browser sense, and they might have opinions as to the benefits >>>>>> and >>>>>> costs we aren't able to easily see. Spec compliance can either be great >>>>>> or >>>>>> pointless, and it would be helpful to get a sense from folks building >>>>>> complex UIs which this is. >>>>>> >>>>>> Best, >>>>>> >>>>>> Alex >>>>>> >>>>>> On Friday, September 12, 2025 at 10:53:50 AM UTC-7 Robert Flack wrote: >>>>>> >>>>>>> > is there any plausible pattern where web developers could depend >>>>>>> on the current behavior intentionally? >>>>>>> >>>>>>> The change in behavior comes in roughly three patterns: >>>>>>> >>>>>>> 1. overscroll-behavior: contain | none is specified on an >>>>>>> element with overflow: hidden. In these cases the >>>>>>> overscroll-behavior used to have no effect, scrolls would propagate >>>>>>> past >>>>>>> the element to ancestor scrollers. In practice, when a developer has >>>>>>> specified this they likely intended to prevent scroll propagation, >>>>>>> however >>>>>>> due to the implementation it had no effect. Authors typically try to >>>>>>> do >>>>>>> this to prevent scrolling while a modal dialog is open from >>>>>>> scrolling the >>>>>>> content behind it, e.g. as in the example posted to the bug >>>>>>> <https://issues.chromium.org/issues/41371072> >>>>>>> https://codepen.io/rctneil/pen/rJYONj. >>>>>>> 2. The author specified overscroll-behavior: contain | none but >>>>>>> on an element with overflow-y: scroll | auto (but implicit >>>>>>> overflow-x: hidden). In this case, they may have accidentally >>>>>>> applied >>>>>>> overscroll-behavior to both axes and not realized that by spec this >>>>>>> prevents overscroll propagation in both axes. I observed this on >>>>>>> https://lichess.org/ though blocking horizontal scrolls on the >>>>>>> open menu would not break using the site. >>>>>>> 3. The author specified overscroll-behavior: contain | none on >>>>>>> an element with overflow: scroll | auto. In this case, we have >>>>>>> the unpredictable behavior that when you have overflow it prevents >>>>>>> propagation, but if your containing element is large enough for its >>>>>>> content >>>>>>> then we don't. This is the common case for things like scrolling in >>>>>>> a chat >>>>>>> widget (demo <https://output.jsbin.com/helovikizu>, bug >>>>>>> <https://issues.chromium.org/issues/40748098>) or in an embedded >>>>>>> frame (bug <https://issues.chromium.org/issues/40736788>). >>>>>>> >>>>>>> Case 1 and 2 are sort of the same, overflow: hidden now preventing >>>>>>> scroll propagation, but in case 1 it never did anything before so it >>>>>>> feels >>>>>>> similar to an author using a property that doesn't work yet. >>>>>>> >>>>>>> If we want to be conservative, we could only change the behavior for >>>>>>> cases where it is currently layout dependent, i.e. case 3 overflow: >>>>>>> auto | scroll. This would be an improvement however it wouldn't >>>>>>> help with case 1 where you want to prevent scrolling from your >>>>>>> component >>>>>>> without risking that containing element becoming scrollable. Cases 1 >>>>>>> and 2 >>>>>>> are possible that developers are relying on this being incorrectly >>>>>>> ignored >>>>>>> and not preventing scroll propagation on overflow: hidden, similar to >>>>>>> for >>>>>>> example ignoring left or top on position: static. >>>>>>> >>>>>>> That said, I do think it would be more useful and predictable for it >>>>>>> to apply to all scroll containers as it is spec'd. >>>>>>> >>>>>>> On Fri, Sep 12, 2025 at 4:15 AM Philip Jägenstedt < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hey Rob, >>>>>>>> >>>>>>>> Since the use counter is 8%, looking at 10 random popular sites >>>>>>>> doesn't reduce the upper bound of breakage by a whole lot. Using the >>>>>>>> rule >>>>>>>> of three <https://en.wikipedia.org/wiki/Rule_of_three_(statistics)> >>>>>>>> gives >>>>>>>> 95% confidence that the rate of breakage is between 0 and 30%. But 30% >>>>>>>> of >>>>>>>> 8% is still a huge number when it comes to potential breakage. >>>>>>>> (Reducing >>>>>>>> this to a reasonable number with more random sampling isn't really >>>>>>>> feasible >>>>>>>> either, you'd need to test 800 sites with only negatives to get down >>>>>>>> to >>>>>>>> 0.03% if my math is right.) >>>>>>>> >>>>>>>> The fact that the change seems to make things work better and >>>>>>>> aligns with apparent developer intention is great. But is there any >>>>>>>> plausible pattern where web developers could depend on the current >>>>>>>> behavior >>>>>>>> intentionally? >>>>>>>> >>>>>>>> In a situation like this I think we should also consider how many >>>>>>>> sites we fix and not just how many we break. If we have high >>>>>>>> confidence >>>>>>>> that many sites will be improved but can't find any that would >>>>>>>> regress, >>>>>>>> then that seems like a good trade even if some regressions do surface. >>>>>>>> >>>>>>>> If other vendors are interested in making the same change and >>>>>>>> there's clear developer demand, I think we should try it, with a Finch >>>>>>>> kill >>>>>>>> switch in place. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Philip >>>>>>>> >>>>>>>> On Thu, Sep 11, 2025 at 10:13 PM Robert Flack <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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 >>>>>>>>> <https://issues.chromium.org/issues/41371072#comment45> 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. >>>>>>>>> >>>>>>>>> On Thu, Sep 11, 2025 at 4:06 PM Robert Flack <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Contact emails [email protected], [email protected] >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EScroll%22> >>>>>>>>>> >>>>>>>>>> Web Feature ID overscroll-behavior >>>>>>>>>> <https://webstatus.dev/features/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 >>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>> ? 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 OverscrollBehaviorRespectedOnA >>>>>>>>>> llScrollContainers >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 [email protected]. >>>>>>>>> To view this discussion visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPripgF_DY4adqs9wbtQV8XRTVdXER3SOR0-52SczULBA%40mail.gmail.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPripgF_DY4adqs9wbtQV8XRTVdXER3SOR0-52SczULBA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>> 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 [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdPV-itQEK%2BbSPAR0u3SfLOqvSEe57TA5SFKRDTODi16g%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdPV-itQEK%2BbSPAR0u3SfLOqvSEe57TA5SFKRDTODi16g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> 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 [email protected]. >>> >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbb963e9-9acb-49b9-ae02-4c82e88d4e6d%40gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbb963e9-9acb-49b9-ae02-4c82e88d4e6d%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b83f3c19-ebd0-4ace-a02d-8151893e8508n%40chromium.org.
