Intent to Prototype: overflow:overlay aliases overflow:auto

[Chris Harrelson]

Contact emails

chri...@chromium.org

Specification

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto

Summary

Removes the overflow:overlay scrolling mode, and makes overlay a legacy alias of auto. overflow:overlay is the same as overflow:auto, except that it does not prevent content from extending into the scrollbar gutter, in cases where non-overlay OS scrollbars are present. (If overlay scrollbars are present, there is no effect.) Example: With overflow:overlay: https://output.jsbin.com/yujenuq/quiet With overflow:auto: https://output.jsbin.com/ruzogaf/quiet

Blink component

Blink>Scroll

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Developers currently relying on content overlapping the scrollbar gutter would instead see some additional line wrapping. Users, on the other hand, would be able to see more content that is currently invisible underneath a scrollbar. On platform configurations with overlay scrollbars in the OS, this change has no effect; it only applies to situations where a non-overlay scrollbar is configured by the browser. Use counter: https://chromestatus.com/metrics/feature/timeline/popularity/2995 Adoption is more than 2% of page loads.

Gecko: Shipped/Shipping (https://github.com/mozilla/standards-positions/issues/768)

WebKit: Shipped/Shipping (https://github.com/WebKit/standards-positions/issues/157)

Web developers: No signals

Debuggability

Sites might not know why their line wrapping changed to exclude the scrollbar gutter. However, this is the existing behavior in Firefox and Safari, so they would get interop by default.

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

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

OverflowOverlayAliasesAuto

Requires code in //chrome?

No

Estimated milestones

Shipping on desktop	114
DevTrial on desktop	114

Shipping on Android	114
DevTrial on Android	114

Shipping on WebView

114

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5194091479957504

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Fri, Mar 31, 2023 at 2:37 AM Chris Harrelson <chri...@chromium.org> wrote:

Contact emails

chri...@chromium.org

Specification

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto

Summary

Removes the overflow:overlay scrolling mode, and makes overlay a legacy alias of auto. overflow:overlay is the same as overflow:auto, except that it does not prevent content from extending into the scrollbar gutter, in cases where non-overlay OS scrollbars are present. (If overlay scrollbars are present, there is no effect.) Example: With overflow:overlay: https://output.jsbin.com/yujenuq/quiet With overflow:auto: https://output.jsbin.com/ruzogaf/quiet

Which platforms would one see a difference between these two? (I'm not seeing a difference on MacOS)

 

Blink component

Blink>Scroll

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Developers currently relying on content overlapping the scrollbar gutter would instead see some additional line wrapping. Users, on the other hand, would be able to see more content that is currently invisible underneath a scrollbar.

I'm assuming that content would avoid overlapping with the gutter before scrolling ever starts, right? (rather than triggering layout shifts once the user scrolls)

 

--
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/CAOMQ%2Bw-F4mOhUMuU3nw423C8CurZKX_wxQvXRPv-XT4Zhsm-XQ%40mail.gmail.com.

[Chris Harrelson]

On Tue, Apr 4, 2023 at 9:21 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Mar 31, 2023 at 2:37 AM Chris Harrelson <chri...@chromium.org> wrote:

Contact emails

chri...@chromium.org

Specification

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto

Summary

Removes the overflow:overlay scrolling mode, and makes overlay a legacy alias of auto. overflow:overlay is the same as overflow:auto, except that it does not prevent content from extending into the scrollbar gutter, in cases where non-overlay OS scrollbars are present. (If overlay scrollbars are present, there is no effect.) Example: With overflow:overlay: https://output.jsbin.com/yujenuq/quiet With overflow:auto: https://output.jsbin.com/ruzogaf/quiet

Which platforms would one see a difference between these two? (I'm not seeing a difference on MacOS)

To see a difference you will have to turn on non-overlay scrollbars in the macOS settings. This feature only has an effect for cases where the OS provides non-overlay scrollbars.

Also: note that this is an I2P, not an I2S. I have not yet done a thorough compatibility analysis of existing sites, but plan to do it soon.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWTkzPKzCF9gGdVHzXKVzDsv921OD-u_JTJv-muV3pkoQ%40mail.gmail.com.

[Yoav Weiss]

On Wed, Apr 5, 2023 at 8:47 PM Chris Harrelson <chri...@chromium.org> wrote:

On Tue, Apr 4, 2023 at 9:21 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Mar 31, 2023 at 2:37 AM Chris Harrelson <chri...@chromium.org> wrote:

Contact emails

chri...@chromium.org

Specification

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto

Summary

Removes the overflow:overlay scrolling mode, and makes overlay a legacy alias of auto. overflow:overlay is the same as overflow:auto, except that it does not prevent content from extending into the scrollbar gutter, in cases where non-overlay OS scrollbars are present. (If overlay scrollbars are present, there is no effect.) Example: With overflow:overlay: https://output.jsbin.com/yujenuq/quiet With overflow:auto: https://output.jsbin.com/ruzogaf/quiet

Which platforms would one see a difference between these two? (I'm not seeing a difference on MacOS)

To see a difference you will have to turn on non-overlay scrollbars in the macOS settings. This feature only has an effect for cases where the OS provides non-overlay scrollbars.

Tried it out and I now understand that my question RE triggering layout shifts doesn't make sense, as the non-overlay scrollbars are always there.

Also, this is a significantly better user experience, so it makes perfect sense to do this! :) 

[Justin Mayfield]

I'm being negatively affected by this change.  I make an Electron app that contains many widget style windows that overlay the screen.  My users place and size these windows with pixel perfect accuracy and I use custom scrollbars that are hidden unless `:hover` is true.  In conjunction with `overflow: overlay` there was no layout shifting on all platforms before 114, but now my windows visibly jank quite badly when hovered because of the layout shift.

Any suggestions on how I might achieve the pre 114 `overflow: overlay` behavior?

Attached video demo of before [7] and after [8] behavior.

[Chris Harrelson]

Hi Justin,

You may find the suggestions in my email here helpful for adjustments for your situation.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02dd8a9c-a13a-4cf4-baf2-3eeab761b394n%40chromium.org.

[Justin Mayfield]

Thanks for the link Chris.

Unfortunately that does not work for my use-case as it's very important for my UX that the margins are perfectly balanced in the un-hover state.  So as ugly as the layout shift is, it's actually better than always having the scrollbar impinging, visible or otherwise.

In that thread I see you also mentioned that work is being done to support cross platform overlay style bars for chromium (Awesome!).  Can we just rollback this deprecation until that work is completed so myself and other users of this feature (however fringe) can continue using modern versions of chromium?  Otherwise I'll have to stay on an old version of Electron/Chromium until the new overlay support is available.

PS:  In the other threads guidance, you recommend trying `visibility: hidden` in conjunction with `scrollbar-gutter: stable`, but the latter is not needed since visibility states don't affect layout.

[Chris Harrelson]

On Mon, Jul 17, 2023 at 3:57 PM Justin Mayfield <too...@gmail.com> wrote:

Thanks for the link Chris.

Unfortunately that does not work for my use-case as it's very important for my UX that the margins are perfectly balanced in the un-hover state.  So as ugly as the layout shift is, it's actually better than always having the scrollbar impinging, visible or otherwise.

In that thread I see you also mentioned that work is being done to support cross platform overlay style bars for chromium (Awesome!).  Can we just rollback this deprecation until that work is completed so myself and other users of this feature (however fringe) can continue using modern versions of chromium?  Otherwise I'll have to stay on an old version of Electron/Chromium until the new overlay support is available.

Unfortunately we won't be able to roll it back. There is however an experimental command line flag you might be able to set temporarily: --enable-features=OverlayScrollbar.

[Justin Mayfield]

Hi Chris,

Thanks for the suggestion,  Unfortunately this does not seem ready for primetime in my initial test.  For this to work as I need, I have to disable my custom scrollbars as they are always treated like non-overlay scrollbars (ie. they impinge when visible no matter what).  So disabling my custom scrollbar (which I really don't want to do, but could live with) results in a flashing scrollbar whenever my content updates.  Hopefully this is just a bug that will be worked out soon.  Attached video showing flashing scrollbar whenever a new paint occurs (note: not hovered for most of the video and it still flashes the bar).

I'm compelled to leave a little negative feedback at the lack of overlap between the CSS deprecation and completion of #overlay-scrollbars.  I've read the arguments and while I don't agree with many of them (specifically no-true-scotsman arguments about how good UX should not use un-impinging scrollbars), I can understand not wanting to carry a non-spec feature forevermore but this feature has been in place for a VERY long time and it works wonderfully for those of us that use it.  The fact that #overlay-scollbars is a WIP should have been plenty of justification for holding off on the CSS deprecation until that work was fully vetted, delivered and adopted. -2c

Thanks for engaging and attempting to help all the same.

Justin

[Justin Mayfield]

Chris,

Has there been any more internal discussion or progress on "overflow:overlay" support being brought back?  If not, can you make suggestions for how this subject might be promoted?  Discussion here (https://github.com/w3c/csswg-drafts/issues/6090) has been shut down unfortunately and I'm afraid this thread is dark now too.

Justin

[Chris Harrelson]

Hi,

Unfortunately overflow:overlay is a non-standard feature and won't be coming back. Ultimately, scrollbar behaviors like this are something that has to be handled at the UA/OS level on behalf of the user, not controllable by the web developer.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHxQA0H1jS1QAUS_6-%2B5GL3U-psw%3DcYfFrCuJpknGSKTcT1bpw%40mail.gmail.com.