[csswg-drafts] [css-scrollbars] Is the track visible in overlay scrollbars? (#9855)

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-scrollbars] Is the track visible in overlay scrollbars? ==
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:
<img width="102" alt="classic" src="https://github.com/w3c/csswg-drafts/assets/113268/11372158-09ae-4bc2-bd82-8142c5f2a59f">

Overlay scrollbars, at rest:
<img width="102" alt="rest" src="https://github.com/w3c/csswg-drafts/assets/113268/306b8205-bf64-4e5b-98ec-e7dafbaf926a">

Overlay scrollbars, scrolling:
<img width="129" alt="scrolling" src="https://github.com/w3c/csswg-drafts/assets/113268/7d8c12bb-2211-45f0-8683-10009d36b322">

Overlay scrollbars, interacting with the bar:
<img width="102" alt="interact" src="https://github.com/w3c/csswg-drafts/assets/113268/b0675858-c8db-4289-ac3e-fcfefa8fbfe0">

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 (https://github.com/w3c/csswg-drafts/issues/9853) on whether authors can deliberately pick a transparent color for the track.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9855 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 25 January 2024 06:04:47 UTC