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.
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.
This improves the ergonomics of overscroll-behavior, fixing the current unpredictable layout dependent behavior we have today.
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.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
No milestones specified
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