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 <sligh...@chromium.org> > 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 <sligh...@chromium.org> >>> 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 <foo...@chromium.org> >>>>> 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 <fla...@chromium.org> >>>>>> 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 <fla...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Contact emails fla...@chromium.org, perry...@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 >>>>>>>> <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 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 >>>>>>>> >>>>>>> -- >>>>>>> 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/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 blink-dev+...@chromium.org. > 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 blink-dev+...@chromium.org. > > 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f51f5de2-d13e-4ef9-9b45-fffa3363bb97n%40chromium.org.
