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

[bramus]

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)

Variant of this: give authors control over this behavoir. Something like a scrollbar-render-track: forced; which authors can choose to put on .scroller or only .scroller:hover if they want. This property is similar to an earlier suggestion of mine to force paint the thumb using scrollbar-render-track: thumb;.

[css-meeting-bot]

The CSS Working Group just discussed [css-scrollbars] Is the track visible in overlay scrollbars?, and agreed to the following:

• RESOLVED: accept proposal as outlined in github, with an exception when the author explicitly sets a fully transparent track.

The full IRC log of that discussion

<TabAtkins> florian: A bit of an issue. With scrollbar-color, authors can (and must) specify two colors, one for the thumb and one for the track
<TabAtkins> florian: It's *the author's* responsibility to ensure that these colors ahve sufficient contrast so the scrollbar is visible and usable
<TabAtkins> florian: Problem is there's no cosntraint on what the UA can do with them.
<TabAtkins> florian: With overlay, there's many situations where the track isn't drawn at all
<TabAtkins> florian: So the author picked two contrasting colors, one might not be used, the other is used against a color they didn't anticipate
<TabAtkins> florian: So we gave the author a responsibility, without giving them assurances they're able to uphold it. that's a problem
<TabAtkins> florian: Several things could be done
<TabAtkins> florian: UAs could show the track all the time, could put a glow/border/shadow/outline around the thumb, they could do this only when they're not showing the track, they could test the contrast for the thumb against the content behidn it and only do the mitigations when needed
<chrishtr> q+
<flackr> q+
<TabAtkins> florian: Lots they could do, don't think we should mandate any particular one, but shoudl mandate they do *something*
<bramus> q+
<TabAtkins> florian: Because a white thumb on a black track, with a white background and no track, isn't good
<TabAtkins> florian: So I prefer to put a UA MUST in the spec, with a suggestion box giving some ideas for accomplishing it
<TabAtkins> florian: There's a bunch of options, just pick one that either allows both author colors to be there, or otherwise ensure contrast
<astearns> ack chrishtr
<TabAtkins> chrishtr: Agree it's infeasible to require a particular scrollbar UX, so I agree with the normative text suggestion that just requires some way to have contrast, with suggestions in informative text
<astearns> ack flackr
<TabAtkins> flackr: Agree as well, same general thing.
<PaulG> q+
<TabAtkins> flackr: May only be necessary to do this if the dev overrode the track color.
<TabAtkins> flackr: So we can say UAs can have a default transparent track color, and if the author overrode that, the UA must ensure contrast
<florian> q+
<astearns> ack florian
<TabAtkins> florian: So the author has to specify both colors right now
<TabAtkins> florian: You're saying if they happen to specify the same track color as what the UA would have done, they don't need to do anything special?
<TabAtkins> flackr: I didn't realize they both had to be specified. But yeah, if the author gives the same track as the UA, they UA doesn't need to do anything.
<TabAtkins> flackr: Maybe a bit unfortunate the author can't just specify a thumb color
<TabAtkins> florian: Reason we didn't allow just a thumb color is the author wouldn't know the track color, and wouldn't be able to ensure contrast.
<astearns> ack bramus
<TabAtkins> florian: But yeah, if they deliberately say a tranparent track, that's a reasonable exception to the "must provide contrast"
<TabAtkins> bramus: An alt to your B suggestion in the issue, is to give authors control to let them force rendering the track
<TabAtkins> bramus: Related to 9785, I needed to force-render the thumb
<TabAtkins> bramus: So like I *really* want a particular track color
<TabAtkins> florian: We could do that too, but as long as it's opt-in we still need what we're discussing here
<TabAtkins> florian: For the other case when the UA is still allowed to not draw the track.
<astearns> ack PaulG
<TabAtkins> PaulG: Is it possible to write a selector that lets author supply two contingencies, for thumb-with-track and for thumb-without?
<TabAtkins> PaulG: If that's the case, UA doesn't necessarily need to do heroics
<TabAtkins> florian: At the moment it's not possible. Could maybe add a MQ, but right now there's nothign
<emilio> 2+
<TabAtkins> PaulG: Okay, in general less magic is better, but if that's a longer/more difficult path, I understand the need for UAs to resolve it.
<emilio> q+
<florian> q?
<astearns> ack emilio
<TabAtkins> emilio: Regarding Bramus's comment, I think force-rendering the thumb is not great because it doesn't match platform conventions - it's weird for scrollbar-color to change how scrollbars work. Users still see familiar scrollbars.
<TabAtkins> emilio: So I'm fine with florian's proposal, but don't think we should force rendering bits.
<bramus> q+
<TabAtkins> emilio: Like in GTK Firefox will only render the thumb unless you're hovering the track, in which case the track will render too. That matches GTK behavior.
<TabAtkins> emilio: So I lik eFlorian's proposal that lets us pick a strategy to ensure contrast while staying within platform conventions
<astearns> ack bramus
<bramus> https://scroll-driven-animations.style/tools/scroll-timeline/params/
<TabAtkins> bramus: There are some use-cases, it's more like a design choice to actively show the scrollbars to make something clear. I'm dropping a demo
<TabAtkins> bramus: I really wanted to show the scrollbars always, even if you only have overlay
<TabAtkins> bramus: We don't need to continue the discussion, just saying there are use-cases
<smfr> q+
<TabAtkins> astearns: Yes, I think forcing scrollbar parts to be displayed is a separate issue
<astearns> ack smfr
<TabAtkins> smfr: I think forcing UA to do treatments on the thumb to make it visible is placing quite a burden on the UA.
<TabAtkins> smfr: In apple the scrollbars are rendered by UI Kit
<TabAtkins> smfr: Having them add shadows or glow or something is quite a burden
<florian> q+
<TabAtkins> smfr: I'm wondering if this puts the whole idea of author-controlled scrollbar colors at risk
<astearns> ack florian
<TabAtkins> florian: The proposal isn't that you have to adjust the thumb, it's that you have to do *something*. Maybe ignore *both* colors if that's fine.
<TabAtkins> florian: Maybe in the Apple case, currently that's fine. Earlier designs, thumb had texture and designs on it, would be visible regardless of color.
<smfr> q+
<TabAtkins> florian: But today's UI where the author can choose good colors and still not get a usable scrollbar isn't fine.
<TabAtkins> +1
<emilio> q+
<astearns> ack smfr
<TabAtkins> smfr: I always considered the colors as providing a base color and the UA can apply subtle effects on top of that
<TabAtkins> smfr: So if the UA can do not a flat color, that's ok
<TabAtkins> smfr: I think the issue is making sure the thumb is readable across different parts of the page, like a zebra stripe background.
<TabAtkins> smfr: So if the UA has flexibility with the colors that's fine
<astearns> ack emilio
<TabAtkins> florian: Yeah, that's mentioned already
<TabAtkins> emilio: We already take some liberties with the color to provide stuff like hover feedback
<TabAtkins> emilio: more directly to Simon's point, I think in Cocoa the thumb has a subtle outline, maybe semi-transparent. That might be enough already to conform to the requirement.
<TabAtkins> emilio: You'll still see the slight outline even with a matching background
<TabAtkins> emilio: So I think AppKit maybe does that already; we copied AppKit's scrollbar rendering and have code to do that, so you did it at some point
<florian> PROPOSED: accept proposal as outlined in github, with an exception when the author explicitly sets a fully transparent track.
<TabAtkins> astearns: Not hearing sustained pushback. [outlines proposal]
<TabAtkins> chrishtr: So part of the normative text will say something about transparent?
<TabAtkins> florian: That wasn't in the original proposal, but was discussed here. If the author gives a transparent track they've already specified their thumb will match their background.
<TabAtkins> flackr: The author has provided two colors that should contrast, and the UA should maintain at least that contrast. If one is transparent, there's nothing for the UA to preserve.
<TabAtkins> chrishtr: So the UA will defer to the author about whether it actually contrasts.
<TabAtkins> flackr: yeah
<TabAtkins> chrishtr: Similar to if you make a white text on white bg, don't do that, not the UA'
<TabAtkins> smfr: Concerned about a transparent track, it can just be invisible then. Should be a provision for the UA to override colors if they're bad
<TabAtkins> florian: Already have that provision, including if the scrollbars just can't be customized.
<TabAtkins> astearns: At this point I think we should get the proposal into the draft and get feedback afterwards.
<TabAtkins> astearns: Concerns or objections?
<TabAtkins> RESOLVED: accept proposal as outlined in github, with an exception when the author explicitly sets a fully transparent track.