[css-scrollbars-1] ability to explicitly request normal scrollbars

[lukewarlow]

This request will refer to non standard CSS so feel free to disregard if it's not really applicable to the standard.

Recently a bug report came up in WebKit.
The report stated that there's no way to undo ::-webkit-scrollbar { display: none } which is true in both WebKit and Chromium.

That got me thinking, the way that these properties are being implemented in WebKit and Chromium is such that an auto value will result in custom ::-webkit-scrollbar styles being applied, but a non-auto value will disable them.

The spec explicitly calls out a CSS override that users can use should they want normal scrollbars as below. However, this won't have the desired effect if custom ::-webkit-scrollbars are applied.

Is this something that should be addressed by this spec? Or is this just an unfortunate state that can't really be fixed.

Note: Users who find the thin style of scrollbars unusable can include the following rule in their user style sheet:
* { scrollbar-width: auto !important; }
This will ensure that all scrollbars are sized as per OS and UA settings regardless of author styles.

[lukewarlow]

At the very least it's probably worth calling out that the legacy styles won't be override by that code snippet in that final line?

[frivoal]

As discussed in https://drafts.csswg.org/css-scrollbars/#out-of-scope

Exposing the scrollbar-related ::-webkit- prefixed pseudo-elements to the Web is considered a mistake by both the CSS Working Group and Webkit.

So the spec is neither defining how it works, nor how to work around it. If we did spec it, I agree with you that making sure it can be overridden would be good, but it's explicitly out of scope, which I think makes this issue non actionable.

Further, while it's unclear how fast this is going to happen, browser vendors have indicated an interest in gradually retiring the scrollbar related ::-webkit-* pseudos.

See https://drafts.csswg.org/css-scrollbars/#out-of-scope and #1969 (comment) for some more explanation about why we're not specifying these pseudos.

With that in mind, I think we should close this issue as out of scope.