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 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
>>>
>>> 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 componentBlink>Scroll
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScroll>
>>>
>>> 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
>>> <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*:
>>>
>>> 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
>>> <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>
>>>
>>> Flag nameOverflowOverlayAliasesAuto
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://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).
>>> None
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://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
>>> <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/f31a4d2e-968e-4a60-8f72-693541cdac0fn%40chromium.org
>>
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f31a4d2e-968e-4a60-8f72-693541cdac0fn%40chromium.org?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+unsubscr...@chromium.org.
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.
