Intent to Ship: overflow:overlay aliases overflow:auto

570 views
Skip to first unread message

Chris Harrelson

unread,
Apr 5, 2023, 8:02:01 PM4/5/23
to blink-dev

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

None

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. However: * I don't think any sites will break for users. * Some sites will improve because they are currently preventing users from seeing some content that is accidentally underneath a non-overlay scrollbar. * Interop will be achieved with Webkit and Gecko. I reviewed 20 sites listed from the HTTPArchive and found nothing broken. The only "downside" was that the visible spacing between content and the scrollbar increased by a few pixels in some cases. In none of these cases was it a significant change to the user experience. On two of the sites, -webkit-scrollbar was also used to make the scrollbar narrower when not hovered, in conjunction with overflow:overlay to reduce the gutter spacing. On those sites, the gutter got a bit wider but the user experience was not materially affected.



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

Other signals:

Ergonomics

After this change, sites will no longer be able to avoid reserving space for the scrollbar. However, this is good, because the scrollbar does take up space and it's bad for users not to be able to read content obscured by it. The CSSWG has in the past considered all of this and resolved not to let developers prevent a scrollbar gutter, because overlay scrollbars are an OS feature, and it's more important for users to see content than for developers to micro-manage an important user affordance. See https://github.com/w3c/csswg-drafts/issues/4501 for example. I found three use cases developers seemed to want to achieve on these sites: * Reduce scrollbar gutter size * "force" overlay scrollbars (there is no way to do that, but overflow:overlay might lead them to that conclusion) * Reduce the gutter when used in conjunction with a custom scrollbar via -webkit-scrollbar that reduces its width when not hovered. Use case 3 is better solved by shipping scrollbar-width in the future (https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-width)



Activation

None



Security

None



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

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

N/A



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

Yes

Flag name

OverflowOverlayAliasesAuto

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=554361

Sample links


https://output.jsbin.com/yujenuq/quiet
https://output.jsbin.com/ruzogaf/quiet

Estimated milestones

Shipping on desktop114
DevTrial on desktop114
Shipping on Android114
DevTrial on Android114
Shipping on WebView114


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/5194091479957504

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-F4mOhUMuU3nw423C8CurZKX_wxQvXRPv-XT4Zhsm-XQ%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Apr 7, 2023, 11:35:21 AM4/7/23
to Chris Harrelson, blink-dev
LGTM1

--
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%2Bw9qXWhmS2ap50fGnKZW%2BzeZe2rX8Lcb%2B2967pZXtt0dHw%40mail.gmail.com.

Mike Taylor

unread,
Apr 7, 2023, 11:38:17 AM4/7/23
to Yoav Weiss, Chris Harrelson, blink-dev

Manuel Rego Casasnovas

unread,
Apr 11, 2023, 11:34:11 AM4/11/23
to Mike Taylor, Yoav Weiss, Chris Harrelson, blink-dev
LGTM3

On 07/04/2023 17:38, Mike Taylor wrote:
> LGTM2
>
> On 4/7/23 11:34 AM, Yoav Weiss wrote:
>> LGTM1
>>
>> On Thu, Apr 6, 2023 at 2:01 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
>>
>>
>>
>> Blink component
>>
>>
>> Blink>Scroll
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScroll>
>>
>>
>> TAG review
>>
>>
>> None
>>
>>
>> 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. However: * I don't think any sites will break for users. * Some sites will improve because they are currently preventing users from seeing some content that is accidentally underneath a non-overlay scrollbar. * Interop will be achieved with Webkit and Gecko. I reviewed <https://docs.google.com/document/d/1KA-eavI44Vc6WTDDlAKvUfv7x2BThTeEY9-bw69Jj2Q/edit#> 20 sites listed from the HTTPArchive and found nothing broken. The only "downside" was that the visible spacing between content and the scrollbar increased by a few pixels in some cases. In none of these cases was it a significant change to the user experience. On two of the sites, -webkit-scrollbar was also used to make the scrollbar narrower when not hovered, in conjunction with overflow:overlay to reduce the gutter spacing. On those sites, the gutter got a bit wider but the user experience was not materially affected.
>>
>>
>>
>> /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
>>
>> /Other signals/:
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
>>
>>
>> Yes
>> <https://wpt.fyi/results/css/css-overflow/overflow-overlay.html?label=experimental&label=master&aligned>
>> Status <https://chromestatus.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.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9qXWhmS2ap50fGnKZW%2BzeZe2rX8Lcb%2B2967pZXtt0dHw%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9qXWhmS2ap50fGnKZW%2BzeZe2rX8Lcb%2B2967pZXtt0dHw%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+...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV%2Bt4QW88ZG2E8GtGX%2Bh%3DGNzqMgcZ5Hvo4KM9mLMWgC_g%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV%2Bt4QW88ZG2E8GtGX%2Bh%3DGNzqMgcZ5Hvo4KM9mLMWgC_g%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+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6a383e1-b175-16d4-e9ad-406a9a45632b%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6a383e1-b175-16d4-e9ad-406a9a45632b%40chromium.org?utm_medium=email&utm_source=footer>.

may b

unread,
Jun 7, 2023, 10:59:42 AM6/7/23
to blink-dev, Chris Harrelson
Hello,

I noticed today while working on our product that the overflow:overlay feature is no longer working. I finally stumbled upon this thread that it has been aliased into auto. I think it's really unfortunate that this feature is no longer available, and for people building web applications, having the scrollbar gutter present can ruin designs, which is why overlay was a nice solution. A use case would be that we have modal windows in our application, and so we hide the scrollbar and show it when content is being hovered on. Our intention eventually was to update it to show overlayed scrollbars only if scrolling (similar to desktop applications like Slack, or the default overlay scrollbars on Mac OS). With the new change, content in flex boxes are completely being shifted. Having the autonomy to choose when and how the user sees the scrollbar would be nice, and for us, this change will require a big workaround to fix every instance in the application.

Attached is a video illustrating the issue without overlay.

Thank you
Screen Recording 2023-06-07 at 13.44.55.mov

Chris Harrelson

unread,
Jun 7, 2023, 12:43:09 PM6/7/23
to may b, blink-dev
Hi,

On Wed, Jun 7, 2023 at 7:59 AM may b <tem...@gmail.com> wrote:
Hello,

I noticed today while working on our product that the overflow:overlay feature is no longer working. I finally stumbled upon this thread that it has been aliased into auto. I think it's really unfortunate that this feature is no longer available, and for people building web applications, having the scrollbar gutter present can ruin designs, which is why overlay was a nice solution.

In general I think the browser needs to be in charge of this, because scrollbars are ultimately a browser feature to help users see content. Over time I hope overlay scrollbars for Chromium will appear on more platforms than just Mac, Android and ChromeOS.

Note also that this feature is not supported in Safari or Firefox, so in both cases the behavior in your video should be present on those browsers when non-overlay scrollbars are used by the browser.
 
A use case would be that we have modal windows in our application, and so we hide the scrollbar and show it when content is being hovered on. Our intention eventually was to update it to show overlayed scrollbars only if scrolling (similar to desktop applications like Slack, or the default overlay scrollbars on Mac OS). With the new change, content in flex boxes are completely being shifted. Having the autonomy to choose when and how the user sees the scrollbar would be nice, and for us, this change will require a big workaround to fix every instance in the application.

In Chromium or Webkit-based browsers, I think you can achieve almost all of this with:

#my-scroller:not(:hover)::-webkit-scrollbar { visibility:hidden }
#my-scroller { scrollbar-gutter: stable }

This will avoid the content jumping like in your video. (It will not allow use of the gutter area for scrolling content though, which I think is good because it avoids obscuring information.)
 
--
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.

fri tz

unread,
Jun 20, 2023, 4:51:44 PM6/20/23
to blink-dev, Chris Harrelson, blink-dev, may b
hi,
I agree with May b. We have been using this feature in our web agency for years and are not happy about this change... The scrollbar track harms modern layouts especially with fullscreen images or horizontal overflow elements like sliders. A scroll function is not always required, e.g. in fullscreen navigations, modals etc... removing the scrollbar by overflow hidden in a modal causes a jump of the content. Overflow overlay prevent this issue. The scrollbar on Mac Safari or Win Firefox are overlayed by default. Why does Chrome go an other way? 

Chris Harrelson

unread,
Jun 20, 2023, 5:25:05 PM6/20/23
to fri tz, blink-dev, may b
On Tue, Jun 20, 2023 at 1:51 PM fri tz <dammi...@gmail.com> wrote:
hi,
I agree with May b. We have been using this feature in our web agency for years and are not happy about this change... The scrollbar track harms modern layouts especially with fullscreen images or horizontal overflow elements like sliders. A scroll function is not always required, e.g. in fullscreen navigations, modals etc... removing the scrollbar by overflow hidden in a modal causes a jump of the content. Overflow overlay prevent this issue. The scrollbar on Mac Safari or Win Firefox are overlayed by default.

There is a project ongoing to add overlay scrollbars to Chromium for Windows and Linux.
 
Why does Chrome go an other way?

Note that overflow:overlay was a non-standard feature only in Chromium. So in cases where Safari or Firefox are using non-overlay scrollbars, they will always show the gutter.

Xianzhu Wang

unread,
Jun 20, 2023, 5:41:42 PM6/20/23
to fri tz, blink-dev, Chris Harrelson, may b
On Tue, Jun 20, 2023 at 1:51 PM fri tz <dammi...@gmail.com> wrote:
hi,
I agree with May b. We have been using this feature in our web agency for years and are not happy about this change... The scrollbar track harms modern layouts especially with fullscreen images or horizontal overflow elements like sliders. A scroll function is not always required, e.g. in fullscreen navigations, modals etc... removing the scrollbar by overflow hidden in a modal causes a jump of the content. Overflow overlay prevent this issue. The scrollbar on Mac Safari or Win Firefox are overlayed by default. Why does Chrome go an other way?

I just tried Safari, Firefox and Chrome on my Mac. All of them follow the system scrollbar appearance setting (System Settings > Appearance > Show scrollbars). They all use overlay scrollbars if the setting is "When scrolling", or "Automatically based on mouse or trackpad" with trackpad. Otherwise they all use non-overlay scrollbars.

Overlay scrollbar has advantages and disadvantages (see crbug.com/801671), so we would like to let users control it based on their preference. For now users can force overlay or non-overlay scrollbars by enabling/disabling chrome://flags#overlay-scrollbars. It's not an official feature though. We prefer the system setting if it's available.

fri tz

unread,
Jun 21, 2023, 3:32:08 PM6/21/23
to blink-dev, Xianzhu Wang, blink-dev, Chris Harrelson, may b
hi,

sry, my mistake: Safari doesn't support overlay scrollbars but Firefox has a native overlay scrollbar since version 100 on all OS. I hope Chromium will do the same or gives us developers the possibility again to overlay scrollbars for a better design.

thank you

Xianzhu Wang schrieb am Dienstag, 20. Juni 2023 um 23:41:42 UTC+2:
On Tue, Jun 20, 2023 at 1:51 PM fri tz <dammi...@gmail.com> wrote:
hi,
I agree with May b. We have been using this feature in our web agency for years and are not happy about this change... The scrollbar track harms modern layouts especially with fullscreen images or horizontal overflow elements like sliders. A scroll function is not always required, e.g. in fullscreen navigations, modals etc... removing the scrollbar by overflow hidden in a modal causes a jump of the content. Overflow overlay prevent this issue. The scrollbar on Mac Safari or Win Firefox are overlayed by default. Why does Chrome go an other way?

I just tried Safari, Firefox and Chrome on my Mac. All of them follow the system scrollbar appearance setting (System Settings > Appearance > Show scrollbars). They all use overlay scrollbars if the setting is "When scrolling", or "Automatically based on mouse or trackpad" with trackpad. Otherwise they all use non-overlay scrollbars.

Overlay scrollbar has advantages and disadvantages (see crbug.com/801671), so we would like to let users control it based on their preference. For now users can force overlay or non-overlay scrollbars by enabling/disabling chrome://flags#overlay-scrollbars. It's not an official feature though. We prefer the system setting if it's available.

Chris Harrelson schrieb am Mittwoch, 7. Juni 2023 um 18:43:09 UTC+2:
Hi,

On Wed, Jun 7, 2023 at 7:59 AM may b <tem...@gmail.com> wrote:
Hello,

I noticed today while working on our product that the overflow:overlay feature is no longer working. I finally stumbled upon this thread that it has been aliased into auto. I think it's really unfortunate that this feature is no longer available, and for people building web applications, having the scrollbar gutter present can ruin designs, which is why overlay was a nice solution.

In general I think the browser needs to be in charge of this, because scrollbars are ultimately a browser feature to help users see content. Over time I hope overlay scrollbars for Chromium will appear on more platforms than just Mac, Android and ChromeOS.

Note also that this feature is not supported in Safari or Firefox, so in both cases the behavior in your video should be present on those browsers when non-overlay scrollbars are used by the browser.
 
A use case would be that we have modal windows in our application, and so we hide the scrollbar and show it when content is being hovered on. Our intention eventually was to update it to show overlayed scrollbars only if scrolling (similar to desktop applications like Slack, or the default overlay scrollbars on Mac OS). With the new change, content in flex boxes are completely being shifted. Having the autonomy to choose when and how the user sees the scrollbar would be nice, and for us, this change will require a big workaround to fix every instance in the application.

In Chromium or Webkit-based browsers, I think you can achieve almost all of this with:

#my-scroller:not(:hover)::-webkit-scrollbar { visibility:hidden }
#my-scroller { scrollbar-gutter: stable }

This will avoid the content jumping like in your video. (It will not allow use of the gutter area for scrolling content though, which I think is good because it avoids obscuring information.)
 
Thank you
On Thursday, April 6, 2023 at 9:02:01 AM UTC+9 Chris Harrelson wrote:
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 componentBlink>Scroll

TAG reviewNone

TAG review statusNot 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. However: * I don't think any sites will break for users. * Some sites will improve because they are currently preventing users from seeing some content that is accidentally underneath a non-overlay scrollbar. * Interop will be achieved with Webkit and Gecko. I reviewed 20 sites listed from the HTTPArchive and found nothing broken. The only "downside" was that the visible spacing between content and the scrollbar increased by a few pixels in some cases. In none of these cases was it a significant change to the user experience. On two of the sites, -webkit-scrollbar was also used to make the scrollbar narrower when not hovered, in conjunction with overflow:overlay to reduce the gutter spacing. On those sites, the gutter got a bit wider but the user experience was not materially affected.



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

Other signals:

Ergonomics

After this change, sites will no longer be able to avoid reserving space for the scrollbar. However, this is good, because the scrollbar does take up space and it's bad for users not to be able to read content obscured by it. The CSSWG has in the past considered all of this and resolved not to let developers prevent a scrollbar gutter, because overlay scrollbars are an OS feature, and it's more important for users to see content than for developers to micro-manage an important user affordance. See https://github.com/w3c/csswg-drafts/issues/4501 for example. I found three use cases developers seemed to want to achieve on these sites: * Reduce scrollbar gutter size * "force" overlay scrollbars (there is no way to do that, but overflow:overlay might lead them to that conclusion) * Reduce the gutter when used in conjunction with a custom scrollbar via -webkit-scrollbar that reduces its width when not hovered. Use case 3 is better solved by shipping scrollbar-width in the future (https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-width)



Activation

None



Security

None



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

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

N/A



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

Flag nameOverflowOverlayAliasesAuto

Requires code in //chrome?False

Sample links
https://output.jsbin.com/yujenuq/quiet
https://output.jsbin.com/ruzogaf/quiet

Estimated milestonesShipping on desktop114DevTrial on desktop114Shipping on Android114DevTrial on Android114Shipping on WebView114

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



This intent message was generated by Chrome Platform Status.
--
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.

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

Chris Harrelson

unread,
Jun 21, 2023, 3:37:06 PM6/21/23
to fri tz, blink-dev, Xianzhu Wang, may b
On Wed, Jun 21, 2023 at 12:32 PM fri tz <dammi...@gmail.com> wrote:
hi,

sry, my mistake: Safari doesn't support overlay scrollbars but Firefox has a native overlay scrollbar since version 100 on all OS. I hope Chromium will do the same or gives us developers the possibility again to overlay scrollbars for a better design.

Hi,

Thank you for the feedback. I agree with you that it would be good for Chromium to support overlay scrollbars natively on all platforms. So far we have them on Android, macOS and ChromeOS. There is also a project underway to add them to Windows and Linux.
 
Reply all
Reply to author
Forward
0 new messages