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 <slightly...@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 <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/CAARdPYdPV-itQEK%2BbSPAR0u3SfLOqvSEe57TA5SFKRDTODi16g%40mail.gmail.com.
