Intent to Ship: 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
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:
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)
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
None
Security
None
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
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 desktop | 114 |
| DevTrial on desktop | 114 |
| Shipping on Android | 114 |
| DevTrial on Android | 114 |
| Shipping on WebView | 114 |
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).
NoneLink 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
--
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
LGTM2
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.
Manuel Rego Casasnovas
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
>>
>> 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:
>>
>>
>>
>> /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/:
>>
>>
>> Yes
>> <https://wpt.fyi/results/css/css-overflow/overflow-overlay.html?label=experimental&label=master&aligned>
>> --
>> 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
>> --
>> 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
> --
> 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
may b
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.
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.
--
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/f31a4d2e-968e-4a60-8f72-693541cdac0fn%40chromium.org.
fri tz
Chris Harrelson
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?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7a963bed-7811-456f-8ec3-1324040d0e3an%40chromium.org.
Xianzhu Wang
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?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7a963bed-7811-456f-8ec3-1324040d0e3an%40chromium.org.
fri tz
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:
Contact emailschri...@chromium.org
Specificationhttps://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto
SummaryRemoves 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
RisksInteroperability and CompatibilityErgonomicsDevelopers 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:ActivationAfter 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)
SecurityNone
WebView application risksNone
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
DebuggabilitySites 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)?YesN/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 changesOpen 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 Statushttps://chromestatus.com/feature/5194091479957504
Links to previous Intent discussionsIntent 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.
--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/f31a4d2e-968e-4a60-8f72-693541cdac0fn%40chromium.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
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5dd15fd8-35a0-4872-a3cf-328ff14c8a9fn%40chromium.org.