Closed nt1m closed 7 months ago
I am in full support of a standardised property across browsers here. However, I would like to suggest this effort should be accompanied by an additional wide
keyword at the very least — auto
is simply not wide enough in some cases.
The -webkit-*
equivalent is frequently used to style the scrollbar to be wider (~24px feels like the common override?) in my casual browsing experience. Having thin scrollbars is pretty rare but can also have its uses in narrow contexts, so I'm glad that's an option but it is pretty strange there is a way to make a scrollbar less accessible and no option to make it more accessible.
For greater interop, it would make a lot of sense to have the scrollbar-width
property implement a wide
value, to at least approximate these use cases with wider scrollbars we can see on browsers supporting full customisations via -webkit-*
pseudos.
A client project I am working on heavily uses data tables that are scrollable. On Chrome/Safari we can show highly-visible wide scrollbars that are easy to find, but on Firefox we are left with a scrollbar that contrasts nicely thanks to scrollbar-color
, but is pretty thin in the context of the app and has been reportedly difficult for some users to "grab", or to even notice. The only way around it would be to implement a custom scrollbar in JS, and I don't think I need to explain why that choice makes my skin crawl.
To go further, it would be even more beneficial to allow for a <length>
as this would allow authors to have a consistent scrollbar on every browser and operating system. I could see some abuse with this (e.g. scrollbar-width: 99vw
) so clamping could make sense here. Note that if scrollbar-gutter is made fully interoperable, it is not as important to have custom lengths as you would be less likely to need to know the scrollbar width for fixed elements and other things that would usually be set to width: 100vw
and could cause horizontal overflow without subtracting the scrollbar width.
( though, arguably, don't this is)
Requests for extra values are better placed in the csswg. This is just about implementing the existing spec.
Having said that requests for a wide/thick option have been filed before and have been mostly shut down from what I can see.
That's not to say don't bother just to temper expectations. I for one think a thick value would be valuable. Especially when viewed in the context of lowering :-webkit-scrollbar
usage.
@lukewarlow You're absolutely right, and I do apologise for my rambling. It felt worth mentioning, since if we're considering having other browsers be spec-compliant, many authors might not use it due to lack of sizing options, so the incentive to change would be low, and the webkit pseudos usage would stay high.
@chriskirknielsen https://github.com/w3c/csswg-drafts/issues/6351 is the original issue requesting wide option. If you do open a new one it's worth giving this a read to see if you can come up with any arguments that have not already been made (the pseudo replacement might be just that)
https://github.com/w3c/csswg-drafts/issues/6263 - is an example of another requesting <length>
support
On that topic and again while the CSSWG is the venue for this it seems worth bringing up here.
https://github.com/w3c/csswg-drafts/issues/9169 - Currently there's no way for a site author (or user through user stylesheets) to force a "normal" width scrollbar. Due to the "auto" value defering to legacy ::-webkit-scrollbar
styles.
Potentially something to think about while reaching interop on the standard behaviour. Of course it's possible the solution is to just unship ::-webkit-scrollbar
but I'm not sure on the compat of that.
Would like to point out that iOS no longer respects the WebKit prefixed selectors either. It's currently not possible in CSS to force a scroll bar to show in iOS.
Not a feature I'd consider a priority. I've tried it and to say I was very unhappy with it would be a massive understatement. At this point, the standard solution is very much lacking, so I'm sticking to a custom JS solution (something I was afraid to go for at first, but after looking at a few implementations, decided rolling my own is something I can do) or, if support doesn't need to go deeper than that, just using the WebKit pseudos.
Chromium intent to ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/PkEsMirl2zE/m/ArphSa39AAAJ
Thank you for proposing scrollbar-width CSS property for inclusion in Interop 2024.
We are pleased to let you know that this proposal was accepted as part of the Scrollbar Styling focus area. You can follow the progress of this focus area on the Interop 2024 dashboard.
For an overview of our process, see the proposal selection. Thank you for contributing to Interop 2024!
Posted on behalf of the Interop team.
Description
(Copied from #417)
Developers need a standard and cross-browser solution to style scrollbars for elements with overflow: scroll;.
There are two alternatives to style scrollbars, the widely supported non-standard ::-webkit-scrollbar- pseudo-elements or the new standard scrollbar- properties defined in the CSS Scrollbars Styling Module spec. Both alternatives are not cross-browser supported.
The non-standard ::-webkit-scrollbar-* pseudo-elements supported by all browsers except Firefox. While scrollbar-width and scrollbar-color properties are supported only by Firefox.
This is not an optimal situation for developers. We need a single solution implemented by all browsers.
Specification
https://drafts.csswg.org/css-scrollbars/#scrollbar-width
Open Issues
No response
Tests
https://wpt.fyi/results/css/css-scrollbars?label=master&label=experimental&aligned
Current Implementations
Standards Positions
https://github.com/WebKit/standards-positions/issues/133
Browser bug reports
No response
Developer discussions
No response
Polls & Surveys
Scrollbar Styling is also a common answer in https://2023.stateofcss.com/en-US/usage/#css_interoperability_features, and in https://2022.stateofcss.com/en-US/usage/#interoperability_features_freeform before that.
Existing Usage
No response
Workarounds
No response
Accessibility Impact
No response
Privacy Impact
No response
Other
No response