[css-scrollbars][css-scrollbars-1] Using scrollbar-color to tint the scrollbar

[felipeerias]

The property scrollbar-color from CSS Scrollbars allows the author to pass two colors, to be used by the thumb and the track of the scrollbar.

So, scrollbar-color: indigo lavender will produce a scrollbar where the thumb is #4B0082 and the track is#E6E6FA.

The spec also advises authors to "ensure the specified colors have enough contrast between them".

I don't know if this has been discussed previously, but what should happen if only one color was provided to scrollbar-color?

scrollbar-color: orange;

scrollbar-color: darkgreen;

My proposal is that when one color is provided to scrollbar-color, it would be used by the UA to automatically define the color scheme for the scrollbar (to "tint" it, so to speak).

This would allow authors to easily style the scrollbars on their pages while the UA ensures adequate accessibility by making sure that the specific colors have enough contrast between them.

[felipeerias]

One starting point to approach this, just to get the ball rolling, could be to use the provided color for the thumb and calculate the track color by keeping the same hue and changing lightness/saturation automatically until the desired contrast is found.

In the first example above, the thumb would be #FFA500 and the track would perhaps be #362B17 (using this contrast checker as reference).

In the second, the thumb would be #006400 and the track would perhaps be #E5ffE5 (reference).

This approach might not work in all cases, for instance with the crimson color #DC143C. For those cases, maybe the thumb color would need to be changed slightly to increase the contrast with the background. For example, scrollbar-color: crimson; might produce a #9e0e2bthumb and a #fae9edtrack (reference).

[frivoal]

This is separate, yet quite strongly related to the issues about accent color: https://github.com/w3c/csswg-drafts/issues/5187 / https://github.com/w3c/csswg-drafts/issues/5480 / https://github.com/w3c/csswg-drafts/issues/5544 / https://github.com/w3c/csswg-drafts/issues/5577

[LeaVerou]

I don't know if this has been discussed previously, but what should happen if only one color was provided to scrollbar-color?

What we recommended was slightly different: that each of the two color values also accepts the value auto, which produces a color generated by the UA. Then a single <color> value can just be a shorter form of <color> auto or auto <color>, whichever is more useful.

One starting point to approach this, just to get the ball rolling, could be to use the provided color for the thumb and calculate the track color by keeping the same hue and changing lightness/saturation automatically until the desired contrast is found.

On a high level, yes. However, as with most things color, this is not as simple and straightforward as it sounds:

• Using HSL lightness leads to unpredictable results, especially when the operation moves toward or crosses the 50% L boundary. E.g. increasing the lightness of hsl(20, 100%, 30%) (brown) by 50% produces hsl(20, 100%, 45%) (orange). Mixing with white or black, even if the interpolation is done in HSL, can produce better results (e.g. hsl(20, 50%, 65%), a light brown).
• Regardless of the lightening/darkening algorithm, if the interpolation is done in a non perceptually uniform space like sRGB and friends (HSL, HWB etc) then we cannot define it as a X% adjustment, as it will produce completely different levels of perceptual difference. For example, here is the same lightness adjustment, on colors of the same HSL lightness (50% to 70%): As you can see, the top pair is way more similar (ΔE2000 = 4.9), whereas the bottom pair is substantially different colors (ΔΕ2000 = 23.9). This can be solved by either interpolating in a perceptually uniform space (e.g. Lab or LCH), or by iterating and measuring the DeltaE between the foreground and background color, instead of having a naïve algorithm that performs the same percentage adjustment each time.
• The high level algorithm itself would need to be different in light and dark mode: in light mode the track is lighter than the thumb, and in dark mode, the track is darker than the thumb.
• What to do in edge cases? E.g. if the thumb is specified as white or black? I suppose it's better to darken instead of lighten and vice versa than to show an all-white or all-black unusable scrollbar.

Footnote: Link to calculations

[felipeerias]

Thank you very much for your detailed feedback, @LeaVerou

I thought that there could be a way to define what would happen if only one color was provided to scrollbar-color, but it seems that this syntax is too ambiguous to provide a good outcome in all cases.

I like your proposal to use a keyword to indicate that a part's color should be automatically calculated by the UA. Do you want to open a separate issue for that?

[frivoal]

I don't think we should get into the details of specifying exactly how the browser computes the contrasting color. It should just do so, in a way that ensure good contrast, and how to do that is up to the UA.

Also, do we want: auto | <color> {1,2} or [auto | <color>]{1,2}? With the latter, when providing a single color, you can decide if it's for the track or the thumb, while with the first one, you just give a tint and let the UA worry about where it goes.

[css-meeting-bot]

The CSS Working Group just discussed single-color scrollbar-color, and agreed to the following:

• RESOLVED: Defer to L2

The full IRC log of that discussion

<fantasai> Topic: single-color scrollbar-color
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/5651
<lea> sorry, was muted
<TabAtkins> fantasai: so one thing discussed is whether scrollbar-color should accept a single color, auto-generating the second color from the first
<TabAtkins> fantasai: another is around allowing 'auto' as a keyword in the two-value syntax, explicitly triggering auto-generation of the other color
<TabAtkins> fantasai: We put it on the agenda to ask if there was interest in allowing this
<emilio> I'd prefer not to add this unless there's strong author demand for it
<Rossen_> q?
<emilio> Not opposed per se but...
<smfr> q+
<fantasai> lea: I think there should be some defined algorithm for UA to generate other color
<fantasai> lea: reasonable for authors to define which color they want to alter, and UA to define other color
<fantasai> lea: Would prefer that option rather than specifying only one color and having magic other color
<fantasai> TabAtkins: ...
<fantasai> lea: Should be possible to specify one color
<fantasai> smfr: Wanted emilio to clarify, want single color to be invalid?
<TabAtkins> s/.../note that the spec currently requires two colors, so we'd first have to agree to allow only one color before the rest becomes relevant/
<fantasai> emilio: So far, Firefox requires 2 colors, and I haven't seen anyone particularly complain about that
<fantasai> smfr: I'm not opposed to a single color, but some ambiguity around whether lightening or darkening to generate the other color
<fantasai> smfr: esp with dark mode
<fantasai> smfr: might need to specify somehow
<lea> q+
<TabAtkins> I'm on the side of "just have the author provide both" (aka no spec change), I think
<Rossen_> ack smfr
<fantasai> lea: wrt dark mode and whether UA darkens or lightens
<fantasai> lea: that has to depend on the color as well
<fantasai> lea: defined which direction to go, then what do you do when author specifies black?
<fantasai> smfr: That's my point, there has to be a defined threshold where UA flips lightening vs darkening
<fantasai> smfr: maybe dark mode is not relevant, mayb authors provide different colors
<lea> q+
<Rossen_> ack lea
<fantasai> lea: I think we're discussing minutiae of specifying a single color
<fantasai> lea: but there's no consensus on whether this is desirable
<fantasai> emilio: Same issue that smfr mentions is already a thing with accent-color
<fantasai> emilio: Scrollbar-color already needs to synthesize other colors, e.g. for :hover effects
<fantasai> emilio: If there's a strong desire to auto-generate track color... I'd rather not
<fantasai> emilio: Authors might get what they want in some browsers and something different in other browser
<fantasai> smfr: Ideal way to specify would be to just use color-5 functions
<fantasai> smfr: Similar to ridge/groove
<TabAtkins> Yeah, unlike accent-color, this is a place where we absolutely know where and how each color is going to be used. Auto-generating colors would be purely a convenience, not a necessity like in accent-color.
<fantasai> s/groove/groove situation
<fantasai> fantasai: main question is, do we want to do this or do we want to defer
<fantasai> Rossen_: what's the consensus?
<fantasai> smfr: I think it's nice to have, but fine to defer to scrollbars-2
<fantasai> emilio: same
<fantasai> Rossen_: proposed to defer to l2, any objections?
<fantasai> RESOLVED: Defer to L2
<fantasai> Rossen_: Encourage folks to engage on the issue and continue discussion there