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/
<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/
<https://cardgames.io/> Seems to just be the
body element that has overscrollBehavior set.
This shouldn't be affected.
3. https://open.spotify.com/
<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/
<https://www.accuweather.com/> Only the body
has overscroll behavior specified.
5. https://www.ikea.com/
<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
<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/ <https://x.com/> Only the
root element seems to have
overscroll-behavior defined.
8. https://store.epicgames.com/
<https://store.epicgames.com/> I'm unable to
find the affected element
9. https://www.airbnb.com/
<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/
<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, 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 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
<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+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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdPV-itQEK%2BbSPAR0u3SfLOqvSEe57TA5SFKRDTODi16g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
