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 <slightly...@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 emailsfla...@chromium.org, perryuw...@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 componentBlink>Scroll >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EScroll%22> >>>>> >>>>> Web Feature IDoverscroll-behavior >>>>> <https://webstatus.dev/features/overscroll-behavior> >>>>> >>>>> TAG reviewNone >>>>> >>>>> TAG review statusNot 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://flagsNone >>>>> >>>>> Finch feature nameOverscrollBehaviorRespectedOnAllScrollContainers >>>>> >>>>> Rollout planWill ship enabled for all users >>>>> >>>>> Requires code in //chrome?False >>>>> >>>>> MeasurementThe 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+unsubscr...@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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPkb0z%2BvW9yo_JQP0q1o54Saa0jkEp9%2Bq6%3DQhHdw7pWRw%40mail.gmail.com.
