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/a4f6e699-a8ab-4afe-bf63-c1040f02d569n%40chromium.org.
