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

[Xida Chen]

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAtpxWMKfSGESe_jUZ6snevi5ESjSQcrfE%2BPG%2BuyX9Toww%40mail.gmail.com.

[Xida Chen]

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]

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.

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.

--
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]

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.

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.

--
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.

[Xida Chen]

Reviving this thread.

Back in February when I sent out this Intent to Ship, our measurement showed that shipping this feature might cause ~2.5% of web page to change their existing behavior.

I have made a lot of progress to drive that number down. Right now, that number is ~0.27% (link, sorry Google Internal only).

At this moment, I am proposing two ways to move this forward:

1. Ask all sites who currently have their non-auto overscroll-behavior in the body element to move to the root element. The problem is that the list of such sites may be very long and we don't have a full list of them.

2. I have proposed a spec change here. If we apply that spec change and make all browser vendors follow the new spec, then there is no need for any site to change at all.

Personally I am in favor of option #2. Please let me know your thoughts.

Thank you.

[Yoav Weiss]

0.27% is still a lot of traffic and presumably a lot of different sites...

If we can convince other vendors to align the spec as you suggest (due to those compat issues), that does indeed sound like a better option.