[css-scrollbars] Scrollbar Hover/Interaction Colors

[ZachHaber]

Spec: https://www.w3.org/TR/css-scrollbars-1/#scrollbar-color

Opening a new issue as suggested in: #9826 (comment)

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.

interaction	Chrome	Edge	Firefox	Safari
Base
Base Thumb Hover
Colored Thumb Hover

---

The solutions I can think of currently are:

1. Allow for more customization of the scrollbars via new properties
2. Standardize something akin to firefox's behavior so that all browsers will have a general approach to ensure that the custom scrollbar colors feel like normal scrollbars.
3. A mix of 1 & 2: default browser behavior, but allowing to override it via properties.

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.

[tabatkins]

For clarity, since I had to poke around in the examples to understand the pictures:

• in each pair, the first is an unstyled scrollbar, the second is given a scrollbar-color that's chosen, for each browser, to make the thumb match the unstyled version
• in the "base thumb hover" row, the thumb of the unstyled (first) bar is being hovered
• in the "colored thumb hover" row, the thumb of the styled (second) bar is being hovered

[tabatkins]

I 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.

[lukewarlow]

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?

[frivoal]

I've made it more explicit in the specification that UAs can adjust the rendering of the scrollbar in response to interaction. I think this resolves this issue. @ZachHaber, does that work for you?

[ZachHaber]

I feel like the word "should" should be used: "Note: Implementations should take advantage..." Other than that, it seems fine to me!

[frivoal]

@ZachHaber In that case, it shouldn't be a Note. A Note explains the reason for or the consequences of pre-existing requirements / allowances. A statement with RFC2119 SHOULD gives new normative expectations.

As phrased, we're just remarking that given how this is defined, this is a thing UAs can do. Whether they actually do it is a question of UI design, and up to them. If we take it out of a Note, and use SHOULD, it because a thing we expect of them (unless they have a good reason not to do it).

Here, I'm a bit on the fence about which to go for. I feel like this is indeed something they should do, but whether a CSS spec is the right place to set expectations on UI component design is less clear to me.

[yisibl]

Can we include ::-webkit-scrollbar-thumb and ::-webkit-scrollbar-track in the specification?

[lukewarlow]

Can we include ::-webkit-scrollbar-thumb and ::-webkit-scrollbar-track in the specification?

I think if we included them anywhere it would be in the compat spec. But we shouldn't standardise their full capabilities imo (and I believe that's the consensus of the csswg based on the notes already in the spec).

Either way that's off topic to this issue so I would raise a new one (if one doesn't exist) for this request.