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/d8d331b0-57c5-4e58-9fc5-cc12861bec6fn%40chromium.org.
