Open ZachHaber opened 1 month ago
For clarity, since I had to poke around in the examples to understand the pictures:
scrollbar-color
that's chosen, for each browser, to make the thumb match the unstyled versionI do agree that simply using the specified 'scrollbar-color' directly in all locations and states is a usability regression; you lose the hover color-change, and the arrow color-change indicating which directions are scrollable. I don't think we need to standardize too precisely about this, because browsers do different things already with the scrollbar designs and we want to allow that flexibility.
So I think this should be treated as a quality-of-implementation issue, but with notes in the spec given recommended behavior - namely, that the provided color should be lightly tinted/shaded (as appropriate for the usage and the color-scheme) to provide these sorts of state indicators.
So to give my two cents as the person who implemented this in Chromium. I completely agree that I missed the mark in terms of implementation quality in this respect. It was something on my radar at one point but it obviously fell off. I think the best solution here is for the spec to recommend affordances such as changed hover styles, and then for the chromium implementation to get those sorts of tweaks.
I'd be interested to hear more about the FIrefox implementation specifics here, do they simply lighten the colour or is there some more smartness going on?
Spec: https://www.w3.org/TR/css-scrollbars-1/#scrollbar-color
Opening a new issue as suggested in: https://github.com/w3c/csswg-drafts/issues/9826#issuecomment-1909275607
For the sake of convenience, I'll refer to the hover as hovering over the thumb/track's arrow buttons, and interaction as holding mousedown on the thumb/track's arrow buttons.
The
scrollbar-color
property has a major pitfall: the appearance changes when hovering/interacting with the scrollbars. There are significant differences between firefox and chromium, but the biggest problem is that in chromium browsers, the scrollbars appear non-interactive if you set a color. There is no change when hovering/interacting with the scrollbar - thumb or arrow buttons. There is also no way to address this issue in chromium browsers with css. Chrome itself has absolutely no interaction changes, while edge reduces the size of the arrows when you are actively scrolling with them. It also has fairly minimal difference between normal and hover states for the thumb.In Firefox, however, there are hover and interaction colors based on the thumb color and track color, though even for the same thumb/track combination, it can end up with different hover/interaction colors than the default for a background.
For safari I'm unsure as they don't have full support for
scrollbar-color
yet.I put together examples of behaviors with matching colors for light/dark scrollbars for chrome/edge/firefox to help highlight how each of the browsers approach it - interesting to note is that unlike chromium, firefox styles the scrollbars based on the color of the background and not the
color-scheme
setting.The solutions I can think of currently are:
For 1 (customizing the scrollbars): there are several different properties that appear for full customization akin to what the browsers do by default currently: For the thumb:
thumb-hover-color
,thumb-interaction-color
. At a minimum for this solution, only these two would be needed. The track parts don't even exist in all browsers (apple has the overlay/minimal scrollbars by default). For the track, both arrow (-arrow-color
) color and track-color
colors are needed:track-button
,track-button-hover
,track-button-interaction
,track-button-disabled
(when fully scrolled in that direction). These could be in two separate properties, or one with two colors for the arrow and for the button.For 2 (standardizing behavior): the specification would just have to make sure that there's some sort of indicator based on hovering/interaction for all of these pieces with a focus on trying to keep an eye on accessibility - whether to lighten/darken for best contrast is complicated and has been discussed many times from what I've seen. I'm not sure how specific this would have to be to make cross-browser behavior consistent, or if full consistency is desired/expected.
For 3 (mix of 1 & 2): Mainly just that the standardizing exists, but you can take control of it explicitly in the css, if you want your design to be 100% consistent between browsers - or if the defaults don't work how you'd like. For the most part, specifying any of the specific extra properties would likely end up as an opt-out for the browser behavior, since, for example, it would be difficult to provide a reasonable interaction color if the hover color is specified and wildly different from the base color.