[css-scrollbars] Is the track visible in overlay scrollbars?

[frivoal]

If the author provides a color for the track (other than transparent), in a user agent set up to use overlay scrollbars, what should happen?

1. The color is ignored, because the track in overlay scrollbars is invisible, and the thumb (when visible) is shown directly over the element
2. The color is used to render the track. The whole scrollbar, track and thumb, may fade in and out as the user interacts with it or not, but when it is visible, all parts of it are visible, and the thumb, if rendered, is always rendered over the track, never directly over the element
3. the color is ignored and the track is invisible while scrolling in general, but used to render the track when the user is interacting with the scrollbar (hovering/clicking)
4. Same as 1, or 3, except that the UA must ensure contrast between the thumb and the element background, by tweaking the color as necessary, when it is painting the thumb directly over the element, without a track.
5. Not defined, up to the UA

I think 5 is not reasonable, because we put the responsibility of ensuring good contrast on the author, which they cannot do if they don't know whether or how the colors are going to be used.

When considering only overlay scrollbars in isolation, I think all of other answers could be considered reasonable. However, authors cannot control nor predict whether classic or overlay scrollbars are going to be used, and this means that 1 is a problem, and to a lesser degree, so is 3. The author may have picked a set of colors whose contrast work well if you use both, but doesn't if you render the thumb against the background of the element instead of against the track.

For instance, imagine a page with a white background, setting up a white thumb against a brightly colored track. With classic scrollbars, the result works. With overlay scrollbars, the thumb is white-on-white, and is invisible.

Currently, Both Firefox and Chrome do 3. Screenshots below are from Firefox using http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12310

Classic scrollbars:

Overlay scrollbars, at rest:

Overlay scrollbars, scrolling:

Overlay scrollbars, interacting with the bar:

As far as I can tell, anything is currently allowed, because the spec says:

Implementations may ignore any of the colors if the corresponding part do not exist on the underlying platform.

But that doesn't seem compatible with putting authors in charge of ensuring good contrast.

We might want to:
a. Add a requirement to the spec that if the user agent ignores one of the provided colors, then the user agent is responsible for providing good contrast, and it may tweak the color of the part that it isn't ignoring in order to achieve that (option 4 above)
b. Require the user agent to paint always paint a track under the thumb if they're painting the thumb at all (option 2 above)
c. Both of these

My take on this would be that we want at least a.

Note that there's also a separate issue (#9853) on whether authors can deliberately pick a transparent color for the track.

[kizu]

I agree that we'd want at least “a”:

Add a requirement to the spec that if the user agent ignores one of the provided colors, then the user agent is responsible for providing good contrast, and it may tweak the color of the part that it isn't ignoring in order to achieve that (option 4 above)

---

For instance, imagine a page with a white background, setting up a white thumb against a brightly colored track. With classic scrollbars, the result works. With overlay scrollbars, the thumb is white-on-white, and is invisible.

There was a recent article by @simevidas about this issue which I feel needs to be mentioned.

[css-meeting-bot]

The CSS Working Group just discussed [css-scrollbars] Is the track visible in overlay scrollbars?.

The full IRC log of that discussion

<luke> q+
<fantasai> florian: Authors have no control, and can't figure out, if they have classic or overlay scrollbars
<fantasai> florian: when setting scrollbar colors, we require that they set two colors, and expect them to pick colors with good contrast
<fantasai> florian: what happens with overlay scrollbars is tricky: is the track even shown?
<fantasai> florian: what current browsers seem to do is, at rest, neither scrollbar thumb nor track shows at all
<fantasai> florian: if you start scrolling e.g. by flicking mousewheel or trackpad, then the thumb shows but not the track
<fantasai> florian: if you start interacting with scrollbars, then both show
<fantasai> florian: I think that's what all browsers do, but it's not specified
<fantasai> florian: If it's unspecified or undependable whether track is shown, how can we expect the author to pick good colors?
<fantasai> florian: if element backround and track are very different colors it's hard to ensure good contrast
<fantasai> florian: Browsers show track always for classic scrollbars, and sometimes for overlay
<fantasai> florian: If you use e.g. brightly colored track with pale thumb, it's usable for classic
<fantasai> florian: but can't see it well when not showing the track
<fantasai> florian: We could require that track is always shown
<fantasai> florian: or allow the UA to ensure good contrast when the track is not shown
<fantasai> florian: There's many complaints about this, I'm not sure entirely what is the best idea
<astearns> ack luke
<fantasai> luke: I don't think we can force-render the track in overlay mode
<fantasai> luke: it's OS-dependent how scrollbars behave
<fantasai> luke: one of the benefits of the standard scrollbar properties is keeping with the OS conventions
<fantasai> luke: Case where thumb is rendering and track isn't, the UA could step in and change the color
<fantasai> luke: spec allows some leeway already
<fantasai> luke: worth specifying, since we have an issue here
<schenney> q+
<fantasai> astearns: One option is to put something in the spec noting this case, if track not rendering then UA must ensure that the thumb is visible
<fantasai> astearns: and leave how that happens up to the UA
<fantasai> florian: That would be good
<fantasai> florian: true that UA has leeway in how to use colors, but not a spec violation to manage contrast -- currently claim it's the author's job to do it
<dholbert> q+
<fantasai> luke: One issue is touch devices, particularly mobile
<fantasai> luke: behavior of scrollbar on a phone is quite different than on a desktop
<fantasai> luke: on a phone, scroll indicator is not super useful, not something you're actively interacting with
<fantasai> luke: the mechanism is the touchscreen, and in those cases the UA might not need to do too much
<fantasai> florian: There are cases on desktop as well where you don't show anything
<fantasai> florian: but if you're trying to show, even as an indicator that you're not interacting with, still want to see it
<fantasai> florian: so "make it visible somehow" is relevant on mobile as well
<fantasai> florian: to the extent you're trying to show it at all
<astearns> ack schenney
<fantasai> schenney: with selection colors we said the UA shouldn't modify them
<fantasai> schenney: hesitant to say that UA can tweak colors here, because authors then can't specify definitively
<fantasai> schenney: hesitant to encourage UAs to change the colors
<fantasai> florian: With ::selection, author gets their background and their foreground
<fantasai> florian: if they get both colors but one of them is tweaked, then there's a problem
<luke> q+
<fantasai> florian: but here we're in situation where they will get only one of their colors
<flackr> q+
<fantasai> florian: in that situation, they're not getting both colors that they expect, then UA needs to do something
<fantasai> florian: goal is the same: to maintain good contrast
<fantasai> florian: mechanics are different
<fantasai> schenney: true, the situation is different
<fantasai> astearns: I could see a UA deciding, for this case where they're not going to render the track, to render the thumb with the specified color with some kind of outline of the track color
<fantasai> astearns: but I wouldn't want to specify that, since that wouldn't be appropriate on all OSes
<astearns> ack dholbert
<fantasai> dholbert: wanted to ask, if white background and white scrollbar thumb, and expecting it to render on some other color
<fantasai> dholbert: unsure if browser can make that visible without some guidance
<fantasai> dholbert: focus ring is reasonable idea to the extent that it fits with the look and feel of scrollbars
<florian> q?
<fantasai> dholbert: might increase contrast slightly if there's some to begin with, but if the colors are identical... I'm stuck to think what's a good way to handle it
<astearns> ack luke
<fantasai> luke: Agree, if property specifies color, should just use that color
<fantasai> luke: at the same time have case with e.g. accent-color where it can change how things are rendered
<florian> q+
<fantasai> luke: we do have algorithm to come up with contrasting glyph
<fantasai> luke: idk if specified or just largely interoperable incidentaly
<fantasai> luke: but could come up with some kind of algorithm for colors
<masonf> q+
<fantasai> luke: I know WebKit in particular leaves scrollbars to platform SDK, can't even change colors
<fantasai> luke: do think it's worthwhile specifying that browsers should deal with this case
<fantasai> luke: even if we can't come up with a must
<astearns> ack flackr
<fantasai> flackr: I'm concerned, in cases where we know the background color it applies
<fantasai> flackr: but default is that most things have transparent background
<fantasai> flackr: so paint on top of ... something
<fantasai> flackr: do browsers then have to figure out what's underneath?
<fantasai> astearns: [example of passing through a zone of color] Do you have to change the color as you go?
<astearns> ack florian
<fantasai> florian: comparison with accent-color doesn't work, because you specify a single color
<fantasai> florian: which is applied to something with geometry
<fantasai> florian: and UAs often do [something], and one of these lines at least will be visible
<fantasai> florian: situation is different. Scrollbars now don't have multiple colors, they're flat
<fantasai> florian: also specifying a pair of colors
<fantasai> florian: can't really respect "the thing" because we're ignoring half of it
<fantasai> florian: given we say authors are responsible for contrast, if the UA ignores half of what author is saying sometimes
<fantasai> florian: then UA must do something to ensure contrast
<fantasai> florian: things we could do:
<fantasai> florian: * ignore the author colors in thumb-only mode entirely
<luke> Yeah that's not a bad idea actually, treat it as auto value in that case
<fantasai> florian: or * [missed next example]
<fantasai> florian: or do some kind of pixel inversion
<fantasai> florian: or tint the color based on what's below it
<fantasai> florian: I don't think we should specify any of them, but require something
<fantasai> florian: which one you pick might be different based on OS
<fantasai> florian: but leaving case where author did something reasonable, but scrollbar is entirely invisible, doesn't seem OK
<fantasai> astearns: concern I have with dropping both colors and going with platform defaults is that there may be cases where designer does have a good contrasting color
<fantasai> astearns: it should be only if the specified color doesn't provide sufficient contrast
<fantasai> florian: what sufficient contrast is is UA defined, no clear boundaries
<dandclark> fantasai: The problem is that the UA can't easily tell what the color is because it's often transparent. Could be many different things. So don't know if that's particularly doable to check the contrast with what you can't see.
<fantasai> florian: allowed to make it conditional, but don't have to require it
<astearns> ack masonf
<fantasai> mfreed: Wrt accent-color, spec doesn't require an algorithm, just requires maintaining contrast
<fantasai> mfreed: algorithm in Blink/Gecko is probably the same because we worked together
<fantasai> luke: if we just drop the fun color, in iOS/Android you never draw the track
<florian> q+
<fantasai> luke: so I think it does need to be conditional on something
<astearns> ack florian
<fantasai> florian: I don't think we would require you to ignore the thumb color, just have to make it visible somehow
<fantasai> florian: This is not "do this particular thing", just "do something"
<fantasai> astearns: We could put a SHOULD requirement, if you're not showing the track and you either can determine that the specified thumb color would not have sufficient contrast or you cannot determine the contrast, then browsers should ignore the specified thumb color
<fantasai> florian: uncomfortable with SHOULD
<dandclark> fantasai: We don't have good answers here.
<fantasai> florian: there is a good answer, just paint the track
<fantasai> flackr: or paint a contrasting outline
<fantasai> florian: either it's solveable, so shoud be MUST, or it's not, in which case we need a better idea
<dandclark> fantasai: Do we want to allow UA to use the track color instead of thumb color?
<fantasai> florian: sure why not
<fantasai> luke: that might not guarantee contrast
<fantasai> luke: shouldn't disallow from doing that
<fantasai> astearns: we're over time, take back to issue
<fantasai> astearns: see if there is some sort of MUST processing that we can agree on
<fantasai> astearns: I don't think we're there yet

[frivoal]

My suggestion would be to add minimal normative text, and as well as informative text:

If the user agent displays the scrollbar without the [=track=], they must ensure reasonable contrast between the [=thumb=] and what is behind it.

Note: This is typically relevant in the case of [=overlay scrollbars=], either on platforms where the [=track=] is never displayed, or on platforms where it is only displayed when the scrollbar is being interacted with but not when scrolling with the mouse wheel or the track-pad. This does not apply in cases where the entire scrollbar is hidden as is often the case with [=overlay scrollbars=] while no scroll operation is ongoing and when the scrollbar is not being interacted with either.

Note: The user agent is free to achieve this by any of a variety of means, depending on the platform, on design choices, or on what is practical to implement, such as:

• Doing nothing if it can determine that contrast is already sufficient
• Doing nothing if the design and geometry of the thumb ensures that some part of it will always be visible regardless of what is behind it
• Adding an outline, shadow, or glow around the [=thumb=] to provide contrast (possibly using the [=track=] color as the contrasting color, or possibly using a different shade of the [=thumb=] color)
• Adding some texture or geometry to the [=thumb=] so that it's color isn't uniform
• Drawing the [=track=] anyway in cases where not doing so yields insufficient contrast
• Replacing the [=thumb=] color with the [=track=] color when that provides better contrast
• Altering the luminosity of the specified [=thumb=] color while preserving its hue
• Disregarding the specified [=thumb=] color altogether and use automatically determined alternative

I think this needs to be a MUST because otherwise authors could pick colors that lead to unusable contrast through no fault of their own.

I think this can be a MUST because it is always possible to implement something that works.

It might be hard to implement given some design choices, but these are choices, and the user agent should be prepared to deal with the consequences of those choices. If the thumb isn't a single flat color with no geometry, no outline, and no shading, then this isn't an issue. If the track is shown whenever the thumb is shown, then this isn't an issue. Yes, user agents can chose to have a flat featureless thumb over no track, but that is what causes this issue, so that choice needs to come with countermeasures.