[css-scrollbars] What do (semi) transparent colors mean for scrollbar-color

[frivoal]

What should the use of fully or partly transparent colors mean for the scrollbar-color property ?

Potential answers could be:

1. ignore the alpha channel, and treat it as an opaque color
2. precompose the (semi-)transparent color against white, and use that as the actual color
3. precompose the (semi-)transparent color against white or black depending on light vs dark mode, and use that as the actual color
4. don't precompose the track's color, and let the background of the element become visible through a (semi) transparent track
5. don't precompose the thumbs's color, and let the track become visible through a (semi) transparent thumb
6. Some combination of the above, doing different things for the thumb and track
7. Don't define, and let it up to the UA.

Because we put the responsibility of ensuring good contrast on the author, I think leaving it up to the UA is not appropirate.

This is related to, but possibly different from the similar question about accent colors discussed in https://github.com/w3c/csswg-drafts/issues/9852: the difference arises because in the accent-color's case, it is the browser's job to ensure good contrast somehow, while in the scrollbar's case, the author provides both colors and is responsible for the contrast. This could potentially result in different conclusions in either case.

As far as I can tell, both Chrome and Firefox currently do something of 4+5, though the way Firefox handles the transparency of the track is a little strange, as you get the same color as Chrome where the horizontal and vertical tracks intersect, but some darker/less transparent shade in each track separately.

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12309 Chrome:

Firefox:

(Note: these results are with classic / non-overlay scrollbars. See also https://github.com/w3c/csswg-drafts/issues/9855 for additional considerations in the case of overlay scrollbars)

[LeaVerou]

I think the alpha channel communicates something about author intent, and author intent should not be ignored. Something like this probably makes the most sense:

precompose the (semi-)transparent color against white or black depending on light vs dark mode, and use that as the actual color

In fact, we don't even need to say "against white or black depending on light vs dark mode", we have a system color for this: canvas.

Just like in #9851, I think it's fine for the UA to use the color to create variations with more or less opacity, but the original color should be honored on at least part of the scrollbar.

[css-meeting-bot]

The CSS Working Group just discussed [css-scrollbars] What do (semi) transparent colors mean for scrollbar-color.

The full IRC log of that discussion

<fantasai> florian: Spec doesn't say what happens to transparent/semi-transparent colors if you specify them
<fantasai> florian: you could ignore the alpha channel
<fantasai> florian: or pre-composite against some color, maybe white, maybe white or black depending on 'color-scheme'
<fantasai> florian: maybe transparent thumb over track is possible, but track is opaque
<fantasai> florian: variety of possible options
<fantasai> florian: e.g. emilio just mentioned making thumb and track invisible
<fantasai> florian: but what about partially transparent?
<fantasai> florian: does the non-colored part of the scrollbar also become invisible?
<fantasai> florian: there's no requirement that scrollbar contains only thumb and track
<fantasai> florian: but in the past, and in some systems still, scrollbars could have up/down buttons as well
<fantasai> florian: do these become invisible as well?
<flackr> q+
<emilio> q+
<fantasai> florian: which options seem reasonable?
<fantasai> florian: Lea commented that alpha channel shouldn't be ignored
<fantasai> florian: suggested pre-composing against white/black
<astearns> ack flackr
<fantasai> florian: or 'canvas', is equivalent to lack/white?
<fantasai> emilio: not necessarily
<fantasai> flackr: Color used for thumb makes sense to apply to other buttons
<fantasai> flackr: maybe make that explicit?
<fantasai> flackr: for transparency, I can see use-cases for semi-transparent thumbs
<fantasai> flackr: maybe make them look frosted or osmething
<fantasai> flackr: maybe keeping their transparency to some extent allowed
<fantasai> flackr: but I don't think the rest of the scroll controls should be made more transparent
<fantasai> flackr: UA should be free to make it clear that the scroll thumb is there
<fantasai> flackr: to be interacted with
<astearns> ack emilio
<florian> q+
<fantasai> emilio: I also have a preference to not special-case transparency
<fantasai> emilio: let stuff be semi-transparent as much as the UA can deal with it
<fantasai> emilio: is there a good reason to not do that?
<fantasai> florian: Here, we're charging to supply both the foreground and background, and thereby ensuring good contrast
<PaulG> q+
<fantasai> florian: They need to know if the alpha channel will be ignored, composed against lack/white, or against content below?
<ntim> +1 to "as the UA can deal with it", some system frameworks may not support it
<fantasai> florian: whichever one we choose, needs to be consistent so author can choose properly contrasting colors
<astearns> ack emilio
<astearns> ack florian
<TabAtkins> fantasai: I agree withi everythign florian said
<astearns> ack fantasai
<TabAtkins> fantasai: ADditional point, let's say you decide to honor the color *and* transparency
<TabAtkins> fantasai: And on one system they use black scrollbars, just an oval on a rectangle, flat color, no distinguishing features
<TabAtkins> fantasai: If you make both thumb and track transparent, it's invisible
<TabAtkins> fantasai: But on another system there's an aqua effect, 3d with some shading
<TabAtkins> fantasai: That shading will exist on a fully transparent bar
<TabAtkins> fantasai: So on that page the scrollbar will still be visible, just "clear"
<TabAtkins> fantasai: So I think we need some kidn of consistency so when an author gets one effect vs the other...
<TabAtkins> fantasai: So if they dev on Mac OS 2001 it looks good, but Mac 2011 you can't see anything at all...
<florian> q?
<TabAtkins> fantasai: So whethe rit's visible and has enough contrast varies depending on style, if you honor transparent colors
<TabAtkins> fantasai: So we need to make sure an author working on one platform can know whether their styles will make a visible or invisible scrolblar, on all platforms
<astearns> ack PaulG
<florian> q+
<emilio> q+
<fantasai> PaulG: I brought up with APA, they offered to help with the language
<fantasai> PaulG: and ensuring contrast/affordances etc.
<fantasai> PaulG: Consistency helps everyone, but even if not consistent, APA is comfortable going forward as long as articulated
<astearns> ack florian
<fantasai> florian: Given fantasai's argument, that pushes us towards precomposing, to get you reliable colors
<fantasai> florian: you could still end up with white-on-white and black-on-black and have that be visible with shading and invisible otherwise
<astearns> ack emilio
<fantasai> florian: but if doing foreground and background are the same, you'll have issues on some platforms -- most platforms currently
<fantasai> emilio: I think we should at least specify that if you provide 0 alpha channel, then the whole thing is transparent, because that's a reasonable use case
<fantasai> florian: why? why not use other ways of making invisible
<kizu> q+
<fantasai> emilio: same as having any element invisible
<fantasai> emilio: use case was showing scrollbar on :hover without layout shift. You can do with scrollbar gutter nowadays but still useful to not have to do any layout to show a scrollbar
<fantasai> emilio: I don't think we need to specify semitransparent colors super deeply
<fantasai> emilio: forcing you to compose on a flat color, that's a bit weird.
<fantasai> emilio: E.g. on linux/firefox you only show thumb. Track is mostly transparent.
<florian> q+
<fantasai> emilio: I think we should leave the rendering of most of these semitransparent colors up to UA and how they can provide a good scrollbar with what they get
<astearns> ack fantasai
<fantasai> fantasai: If we want invisible scrollbars, have a keyword for that. Transparent won't guarantee invisible scrollbars
<fantasai> emilio: I don't feel super strongly, but fading a scrollbar by animating alpha channel is nice
<TabAtkins> fantasai: if scrollbar is shared, it'll aniamte from clear to purple or wahtever, it just won't actuallyb e invisible because the shading will be there
<fantasai> emilio: I don't think current platforms do shading
<astearns> s/shared/shaded/
<fantasai> emilio: if fully transparent is actually invisible, then the animation would work in such a platform
<flackr> q+
<astearns> ack kizu
<fantasai> kizu: Maybe this could be considered alongside another issue, 9855 about the track and overlay scrollbars and setting colors
<fantasai> kizu: if we could require UAs to make the thumb and track to always have contrast, we should do it
<fantasai> kizu: and then we might make an exception for completely transparent scrollbars for authors that want to make it completely invisible but still take space
<fantasai> kizu: I'm not sure if we want to provide this use case, or always want hidden scrollbars [missed]
<fantasai> kizu: issue with making this a special case is that it might not work for UAs for transitions, if you want to have scrollbar appear if UA chooses to precompose colors against some other colors
<fantasai> kizu: if we precompose completely invisible, at zero it disappears immediately. That's maybe an issue
<astearns> ack florian
<fantasai> florian: I'm open to a variety of option, but what is not reasonable is to not specify
<fantasai> florian: if the author can't know if precomposed over white or black or actual element background, they can't ensure their colors provide contrast
<fantasai> florian: because they don't know what their colors mean
<fantasai> florian: so we can't allow one or the other, we have to pick one.
<fantasai> florian: Emilio is leaning towards "don't precompose"
<fantasai> florian: Another question in another issue about whether you're required to paint the track at all in overlay scrollbars, hoping to keep separate
<emilio> q+
<astearns> ack flackr
<fantasai> florian: desire that you see things the same suggests an alternative, require that we use the opacity from the color for the rest of the painting even if it is shaded
<ntim> Some system frameworks don't support alpha, so if we specify anything i'd rather have it be simple
<fantasai> s/florian/flackr/
<fantasai> flackr: unsure if that's ideal, but would allow things to fade consistently
<fantasai> flackr: but maybe if fully transparent don't want it to hit test either
<fantasai> flackr: so maybe separate property
<astearns> ack fantasai
<TabAtkins> fantasai: If fading the scrollbar is something people really want, we shoul dhave scrollbar-opacity that controls it all, including the parts the author isn't coloring
<TabAtkins> fantasai: Lots of things potentially in a scrollbar that potentially aren't under author control
<astearns> ack emilio
<TabAtkins> fantasai: But downside of making it transparent when not hovering - if the element has focus but not hovering, and someone assuming it's only scrolalble when there are scrollbars, someone using a differnet mechanism won't know it's scrolalble
<florian> qq+
<fantasai> emilio: similar thing with accent-color, and e.g. Chromium ignores alpha channel, Firefox tries to deal with it, and unsure about WebKit
<ntim> AppKit doesn't support changing scrollbar colors, so neither does WebKit
<fantasai> florian: answer might be the same, but for accent-color, it is different because in that case the author is only providing one color -- UA is charged with providing good contrast
<emilio> *?
<fantasai> florian: but for scrollbars, the author needs to ensure contrast
<fantasai> florian: Either UA ensures contrast, or we specify how the colors composite so the author can know whether they get good contrast
<astearns> ack florian
<Zakim> florian, you wanted to react to emilio
<bramus> q?
<fantasai> astearns: I think I'm convinced that we should not try to solve the fully-transparent case with scrollbar colors because there are other bits of the scrollbar which may not be under these colors' control
<fantasai> astearns: I find that logic compelling
<ntim> WebKit does ignore alpha for accent-color
<fantasai> florian: if we go that way, then do we specify semi-transparent colors to be pre-composed? I think these two go together...
<fantasai> astearns: yes, but less convinced about that
<fantasai> astearns: Anyone want to argue for ignoring alpha channels in scrollbar colors entirely?
<fantasai> florian: What you propose seems reasonable, may be other options
<ntim> pre-composing is hard because we don't know what background to use
<fantasai> astearns: 2 options are ignoring or pre-composing
<fantasai> fantasai: Lots of points brought up in this discussion, might be good to list the good options and pros/cons, and resolve later

[frivoal]

Here's a tentative summary of where we stand, based on the last call:

While not directly the topic of this issue, there was a proposal made that might help with it, at least in part: that if a thumb color is provided, it applies no only to the thumb, but also to any control other than the thumb that might appear on the track, such as scroll-up or scroll-down buttons.

(regardless of the rest, I'm in favor of adopting this part)

As for the main question of this issue, I think the options being considered are:

1a. specify that both thumb and track do respect transparency, without precomposition, (and so the track shows through the thumb and the background shows through the track); also special-case a fully transparent thumb and track to make the entire scrollbar invisible, even if it includes parts that are not otherwise colored (shading, texture, highlights, additional controls besides the thumb…)

1b. specify that both thumb and track do respect transparency, without precomposition; also that their alpha channel is also applied to the non-colored parts of the scrollbar. I think this is equivalent to saying that thumb and track are first colored ignoring the alpha channel, then the alpha channel of the thumb/track color is applied to the whole thumb/track, including both colored and non colored parts.

2a. Address scrollbar opacity through a separate scrollbar-opacity property; the alpha channel in scrollbar-color is ignored.

2b. Address scrollbar opacity through a separate scrollbar-opacity property; the alpha channel in scrollbar-color is precomposed (presumably over the named canvas color, although we didn't spend much time discussing which color to precompose against).

We also discussed a "don't specify" option, but consider if off the table, because (at least) I would object to that: we cannot task authors with ensuring good contrast if they cannot know whether transparent will mean invisible (non-precomposed), black (ignore alpha), white (precompose against white)…

Personally, I'm in favor of 2b.

[frivoal]

While not directly the topic of this issue, there was a proposal made that might help with it, at least in part: that if a thumb color is provided, it applies no only to the thumb, but also to any control other than the thumb that might appear on the track, such as scroll-up or scroll-down buttons.

(regardless of the rest, I'm in favor of adopting this part)

Actually, I changed by mind on this. I think it is reasonable to allow the UAs to do that, but not to require that they do, as there exist scrollbar designs where the thumb is colored but the buttons are not.

[bradkemper]

I initially preferred 1b, as it seemed fairly intuitive for the author. But then, I think a common case would be having a translucent thumb color but still have the white highlights and dark shadows of the UA shading be at full opacity. So I think 2b is best.

The precompositing would just be of the alpha channel, so I don’t think the canvas color would enter into that operation, right? You’d just be multiplying the pixels of the color alpha channel with the value of scrollbar-opacity. Once you have the calculated opacity for each pixel, whatever was behind it in the z axis would be revealed to that degree for that pixel.

And presumably the thumb would be in front of the track in the z axis.

[css-meeting-bot]

The CSS Working Group just discussed [css-scrollbars] What do (semi) transparent colors mean for scrollbar-color, and agreed to the following:

• RESOLVED: transparent colors in the thumb are transparent towards the track, and transparent colors in the track are transparent towards the background; transparency in those colors is not generalized to the entirety of the scrollbar

The full IRC log of that discussion

<matthieud> florian: this is abut transparent color for scrollbar-color property
<matthieud> that property takes 2 colors one to the thumb, the other applied to the track
<matthieud> what does transparent means here ?
<matthieud> depend on the operating system, depend between current and older one, they sometimes have design like shaded bottom ...etc...
<matthieud> currently it is not specified how this property affect those other parts
<matthieud> so what do we do with "transparent" (many possible design choices)
<matthieud> in general, browser applies it to the background
<matthieud> we also discovered that some people use entire transparent to make scrollkbar disappear
<matthieud> if it has a bottom(?) what happens.
<matthieud> maybe we need a specific property like scrollbar-transparency or scrollbar-opacity
<miriam> s/bottom(?)/button
<matthieud> even if we only think about the thumb, given a semi transparent color doesnt apply on the whole thing
<matthieud> one way out of it it to be explicit neither the thumb color nor the track color are pre-composed in any way nor ignored
<matthieud> for the use case of making the whole scrollbar transparent we can make a separate property
<matthieud> one important tthing: we need to specify something. right now its the author who is in charge of good contrast
<matthieud> ignoring transparency means black \
<matthieud> if we dont specify the behavior, the author cant ensure good contrast
<matthieud> proposal : there is no magic that apply the transparency of those color to the entiere of the scrollbar
<matthieud> (if we want that, it should be a separate property)
<matthieud> this color has used by UA to shade the various parts
<miriam> +1
<matthieud> the thumb is tranparent toward the track, and the track toward the background
<matthieud> what about pre-composition ?
<florian> s/the thumb is/the colored part of the thumb is
<matthieud> florian: current UA compose toward the background
<matthieud> not transparent toward the potential text on top
<florian> s/toward the background/toward the background, including images and gradients…
<matthieud> astearns: if we resolve to that, is there change to UA necessary ?
<matthieud> florian: not really
<matthieud> when they have flat track/thumb, they already do that
<matthieud> when you have a non flat scrollbar, you cant assume that transparent means disappear scrollbar
<matthieud> however if we go the other way, there might be discontinuity (cf aqua or windows scrollbar)
<matthieud> in an old fashion scorllbar design if you apply a semi transparetn color only to the colored parts, that would make the whole scrollbar disappear : weird
<florian> s/, that would make the whole scrollbar disappear : weird/but apply fully transparent to the whole scrollbar, then there's a discontinuity at very-but-not-fully transparent
<matthieud> whatever we decide today, we are not gonna resolve a new property to control scrollbar opacity today
<matthieud> florian: maybe this is a prerequired to resolve the rest
<matthieud> PROPOSED: we specify what UA are currently doing with transparent color on their flat scrollbar today
<matthieud> the WPT tests are not testing what is in the spec
<matthieud> PROPOSED : we also note that it doesnt mean that all scrollbars will be totally transparent (its true currently, but a coincidence)
<florian> PROPOSED: transparent colors in the thumb are transparent towards the track, and transparent colors in the track are transparent towards the background; transparency in those colors is not generalized to the entirety of the scrollbar
<matthieud> note that we might need to define precisely what "background" means here ?
<astearns> RESOLVED: transparent colors in the thumb are transparent towards the track, and transparent colors in the track are transparent towards the background; transparency in those colors is not generalized to the entirety of the scrollbar
<fantasai> some discussion about how UAs paint over the background directly, not over e.g. text content underneath
<matthieud> florian: non flat scrollbar already exist on Linux
<florian> s/exist on Linux/exist on at least Linux