Intent to Ship: Propagate overscroll-behavior from html / root

119 views
Skip to first unread message

Xida Chen

unread,
Feb 16, 2021, 10:12:33 AMFeb 16
to blink-dev

Contact emails

fla...@chromium.org, liviu...@chromium.org, xida...@chromium.org


Explainer

https://developer.mozilla.org/en-US/docs/Web/CSS/overscroll-behavior


Spec

https://drafts.csswg.org/css-overscroll-1/#propdef-overscroll-behavior


Tracking bug

crbug.com/954423


Summary

The overscroll-behavior CSS property sets what a browser does when reaching the boundary of a scrolling area. It is a shorthand for overscroll-behavior-x and overscroll-behavior-y.


Chrome fully supports this feature since M63. However, there is a known bug that the overscroll-behavior is propagated from body element to the viewport, where the correct behavior is from html to the viewport.


We intend to fix the bug and ship the correct behavior. The current measure shows that this change might cause different behavior on ~2% of web pages. These 2% web pages can be broken down into two cases:

  1. The sites that will now prevent overscroll after the fix. In this case, the developer already wanted to prevent overscroll, so the fix shouldn’t harm their sites.

  2. The sites that will now no longer prevent overscroll after the fix. In this case, a site would have overscroll prevent set in the body, but not in the html. After the fix, the behavior would be consistent with Firefox and Safari (which doesn’t yet implement the overscroll-behavior). Given the incomplete support of overscroll-behavior, it’s unlikely that this will break sites. Moreover, when it does initiate overscroll it does show a UI affordance which lets the users know what is happening.


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Demo

Here is a demo that reflects the buggy case.


Risks

Interoperability and Compatibility

Firefox: Full support from M59

Edge: Not fully supported.

Safari: No signal


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

We will ensure that there is test coverage for the buggy case under this test suite.


Entry on the feature dashboard

https://www.chromestatus.com/feature/5734614437986304


Majid Valipour

unread,
Feb 16, 2021, 3:39:27 PMFeb 16
to Xida Chen, blink-dev
Hi,

I am very glad you are working to fix the interop issue given that I feel partly responsible for this mistake in Chromium's implementation.

FWIW, I know that this css property is used by some major Google sites. Not that this should prevent you from changing in semantics but perhaps reaching out to them could help reduce the current 2% page load usage with web-compat impact.

Also I believe there is a reasonable and simple fix that many existing sites can apply such that their current behavior is not impacted with the proposed semantic change. 
Having a simple fix and documenting it would make this easier for web developers that need to deal with web-compat impact.

```css
/* OLD: This is what a site may be doing currently to prevent pull-to-refresh or swipe navigation in Chrome. */
body {
  overscroll-behavior: none;
}

/* NEW: By additionally specifying the property on html their desired behavior would continue to work after the change. */
body, html {
  overscroll-behavior: none;
}
```

Majid


--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAu%3DCDnPDv8nerEr6YvLTeeCM2T0SsxTWP%2B2nbBWKgmQaw%40mail.gmail.com.

Xida Chen

unread,
Feb 17, 2021, 9:52:49 AMFeb 17
to Majid Valipour, blink-dev
Hi Majid,

Thank you for your suggestions, this is very helpful to us. I will reach out to the owners of those Google sites and try to make this transition smoother.

Daniel Bratell

unread,
Feb 18, 2021, 4:17:44 PMFeb 18
to Xida Chen, Majid Valipour, blink-dev

From an API owner perspective, the 2% number is in a range where we need to understand more what is affected.

I understand that it's unlikely to cause serious breakage, but if usage could be driven down by changing those sites you are talking about, that would make the decision less risky. Could you return when you have more information about that, and we could continue from there?

/Daniel

Xida Chen

unread,
Feb 18, 2021, 8:20:20 PMFeb 18
to Daniel Bratell, Majid Valipour, blink-dev
I think that makes sense. I will reach out to the Google sites that use this property and drive down that number.

Thanks.

Yoav Weiss

unread,
Mar 18, 2021, 6:12:51 AMMar 18
to blink-dev, Xida Chen, Majid Valipour, blink-dev, Daniel Bratell
Any news on this intent?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.

Xida Chen

unread,
Mar 18, 2021, 8:46:40 AMMar 18
to Yoav Weiss, blink-dev, Majid Valipour, Daniel Bratell
I have been working on this with owners of some Google sites but unfortunately I am not seeing the number going down.

For now, I think it makes sense to put this intent on hold, until I see data from Chrome Platform Status on the "Adoption of the feature on top sites". Then I can work with those sites to drive the number down.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
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+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages