Defining -webkit-scrollbar
Opened this issue · 21 comments
Not necessary a have to. Just putting here to understand the usage and be sure we are not missing anything about it.
- check implementation in Edge
- check issues in other browsers
- check level of usage on the Web
- check how it is implemented in Blink/WebKit
Currently on the Firefox front, there are a couple of issues with it.
- Google calendar columns in week view are misaligned on Retina Mac & with full-page-zoom on other platforms, due to "wk-dummyth" element being a different size from the scrollbar
- Google Mail has horizontal scrollbars in 3-panel mode
- html5 youtube player: vertical scrollbar width obscures quality settings text
- www.twitch.tv - webkit-scrollbar
I didn't find any stats for it on https://www.chromestatus.com/metrics/css/popularity#webkit-scrollbar
This is not very encouraging. On Github We’ve found 210,423 code results
Since there isn't a Blink usecounter for this feature, we could do an httparchive analysis similar to whatwg/html#668 (comment). @zcorpan any pointers on where to start with that?
See https://www.igvita.com/2013/06/20/http-archive-bigquery-web-performance-answers/
https://discuss.httparchive.org/ for more example queries.
cc @igrigorik
Thanks!
Just found myself here while googling information on customizing scrollbars for a cleaner UI element for a new social web-app. Although sites like slack, twitch, and discord all seem to have custom scrollbars, there is no clear "right-way" implementation that I can find and all rely on polyfill/hacks. Is this something being discussed?
To note that a specification has been started about this a little while ago.
https://drafts.csswg.org/css-scrollbars/
Could it be worthwhile specifying that ::-webkit-scrollbar { display: none; } should be implemented? I believe this is probably the only styling that could lead to breakage if it was removed, and could improve firefox compat if it was added.
Potentially the rest of the legacy scrollbar styling could be removed once Chrome and Safari have shipped the standard properties? (at least scrollbar-width is in progress in both)
@lukewarlow, it's probably also worth handling width:0 similarly to display:none, as I'm quite sure I've seen it used as well on live sites in my webcompat work before.
Do we expect any push-back from sites not being able to set specific widths, or specify colors on specific parts of the scrollbar?
Given they already can't do that in Firefox I can't see how they could take issue with it? scrollbar-width at least allows for hiding and requesting thinner bars when space is limited.
scrollbar-width at one point accepted a value but it was removed, given this I think we're probably safe to assume that removing that level of customisation is acceptable at least to the csswg?
Other forms of hiding are definitely worth investigating as you say.
https://groups.google.com/a/chromium.org/g/blink-dev/c/PkEsMirl2zE/m/ArphSa39AAAJ just as an FYI I've filed an intent to ship in Chrome for the standard properties.
Excellent!
So the question now is more about ::-webkit-scrollbar, is it necessary to describe it in the compat spec. Or everything is covered by the CSS spec now.
Note that the spec has this note…
NOTE: Exposing the scrollbar-related ::-webkit- prefixed pseudo-elements to the Web is considered a mistake by both the CSS Working Group and Webkit.
But how much of the Web would break if browsers decide to stop exposing to the Web?
There is still no usage counter about it
https://chromestatus.com/metrics/css/popularity#webkit-scrollbar
It'd be good if we could add one for usage in general (maybe another for usage that won't be ignored by standard property usage) and another for the display none case specifically.
I suspect we can get away with just speccing hiding of scrollbars and nothing else if we have to spec anything for web compat.
I was thinking of adding an on by default flag to chrome that controls the legacy behaviour so I can disable it and see how much breaks but I noticed some internal uses that will need migrating first.
I recall there was a firefox bug that discussed implementing this (at least a minimal case) for compat reasons and the conclusion seemed to be that the performance could be an issue. So that's worth considering too.
it's probably also worth handling width:0 similarly to display:none, as I'm quite sure I've seen it used as well on live sites in my webcompat work before.
Interestingly Safari on iOS doesn't support any of the webkit scrollbar styling except for the below code. Admittedly mobile overlay scrollbars are quite a bit less of an issue than classic desktop ones that could take up space etc. Potentially a path towards deprecation could be moving towards this same limited implementation on Android Chrome? Would need use counters etc first I suspect.
::-webkit-scrollbar {
display: none;
}
There are a couple of site interventions in Firefox.
https://github.com/search?q=repo%3Amozilla-extensions%2Fwebcompat-addon%20scrollbar&type=code
The webcompat issue on Mozilla is
https://bugzilla.mozilla.org/show_bug.cgi?id=1432935
the important part is to look at the SeeAlso which are being added time to time.
There is still no usage counter about it
https://chromestatus.com/metrics/css/popularity#webkit-scrollbar
So I finally (sorry for the delay) got round to adding use counters and found that actually some already do exist.
https://chromestatus.com/metrics/feature/timeline/popularity/582 - ::-webkit-scrollbar
https://chromestatus.com/metrics/feature/timeline/popularity/583 - ::-webkit-scrollbar-button
https://chromestatus.com/metrics/feature/timeline/popularity/584 - ::-webkit-scrollbar-thumb
https://chromestatus.com/metrics/feature/timeline/popularity/585 - ::-webkit-scrollbar-track
https://chromestatus.com/metrics/feature/timeline/popularity/586 - ::-webkit-scrollbar-track-piece
These provide an upper bounds of compat risk of removal. Obviously not all usage is equal and this doesn't account for when the standard properties are additionally used.
this doesn't account for when the standard properties are additionally used.
I've just realised that it will in fact account for this once Chrome 121 is stable, so the usage from January onwards will hopefully drop as the use counter wont be hit when standard styles are used.
Do we expect any push-back from sites not being able to set specific widths, or specify colors on specific parts of the scrollbar?
@wisniewskit so some feedback that came up on Twitter when the suggestion to make scrollbar-width and/or scrollbar-color Interop 2024 focus areas, was that scrollbar-width isn't flexible enough.
Specifically people didn't like that it was limited to auto, thin, and none; a thick value (or font-size style xlarge) or the ability to set an arbitrary pixel value came up.
I've also separately seen requests for a "wide" value raised in the CSSWG issues board. (w3c/csswg-drafts#6351), along with arbitrary size support (w3c/csswg-drafts#6263)
So this is potentially an area to revisit, although there seems to be particularly strong implementor push back on both these ideas.
I didn't see any complaints about the scrollbar-color property but there may be some.
Circling back to this just to say apologies but I haven't had the time to investigate adding additional use counters, so if someone else wants to go ahead.
Not really been long enough to see the impact of Chromium supporting standard css scrollbar styling yet but https://chromestatus.com/metrics/feature/timeline/popularity/582 there's a slight drop since january. Though not as large as i'd hoped.