[css-scrollbars] Flaws in the Spec for `scrollbar-color`

softworkz commented 9 months ago

Spec in question: https://www.w3.org/TR/css-scrollbars-1/#scrollbar-color

Invalid Preposition

The design of this spec is based on the incorrecct assumption that "when a web developer would want to customize the scrollbar coloring, they would always want to specify both, background and thumb color" (as it's been said somewhere in the discussion).

This is quite untrue. There are many use cases where you want to specify only one color but not the other. Of course the obvious idea behind makes sense in its simplistic nature, that when you want to have a black element (thumb and button) color, you would specify a light color for the scrollbar track background in order to ensure that there's sufficient contrast (as a UA may be configured to have a black track background). But web design is not black and white only. There are countless cases where you want to specify only one of those colors but not the other one. I'll give an example for each case:

Example 1: Thumb Color Only

You might for example design web content which adapts according to the user's system theme (light or dark). You have an accent color in your design and you want the scrollbar thumb to be painted in this color (could be same or diferering by light or dark presentation). You want to provide a seamless experience on each platform, which means that you don't want to have any visible differeces between

The scrollbar background appearance and other applications on a user's system
The scrollbar and your main content You might not specify an actual background color and leave it to the browser or OS setting instead - whatever that may be for light or dark display modes

The spec in its current form forces you to specify a background color - but you cannot know the right one. It's not always White on light themes and Black on dark themes (especially not in the latter case).

You could specify transparent for the background as a workaround - but in your design, it might be required to have an opaque color in order to avoid any content below from being visible.

Example 2: Track Color Only

I will focus on what will probably be the Number 1 use case for scrollbar-color: Making scrollbars transparent

For a long time it has been really cumbersome to achieve srollbar transparency in web designs, because you had to choose between

Either not having transparent scrollbars in exchange for a consistent and platform-conformant appearance
Or use custom browser specific methods which give you a lot of freedom in creating a scrollbar appearance which can be customized in countless defails - which is great on one side. But on the other side - it also forces you to create a detailed custom scrollbar appearance, while all you would have wanted is to have the platform-specific appearance of scrollbars, just with a transparent background.

Now - this spec would (and should) be the great relief for all the pain which was previously involved in leveraging scrollbar transparency for web designs. But in its current form it is not suitable to do so.

Once again, it forces web developers to do something that they don't (always) want to do: specifying a thumb color. When you you have transparent scrollbars, you often still want the scrollbar thumbs to have the original platform-default color which matches the theme of the UA and other apps in the environment. There's no reason for you to change that (in the majority of cases).

Example 2b: Embedded Web Content

Scrolbar transparency is also important for cases where web content is embededded into other applications via webview controls. In that case, you might want to be able to see-through to the application's window background - but again, you don't want to specify the thumb color as you still want that to be controlled by app/OS settings. Please see my other posts on this subject:

Accessibility Concerns

In the spec design, accessibility concerns have been given as an argument for requiring both color values to be provided - or none. This kind of reasoning makes sense in cases, but it was a bit short-sighted. Considering real-life cases, I rather think it's the other way round:

Forcing both values to be provided will cause web designers to make bad decisions - like so often when somebody is forced to decide on something they cannot decide in a good way. Cases where a web designer sets a black thumb and "forgets" to set a light background or similar are rather rare. This is basic and obvious knowledge nowadays that there are different systems which may have different system colors. Not that rare will be cases where a designer wants to have a transparent track background and is forced to set a thumb color. Of course they will choose one that matches on their system, but then it might be the wrong choice for other platforms where the scrollbar might not be well distinguishable anymore.

Another example would be cases where users have configured high-contrast themes for accessibility reasons. The scrollbar-color overrides such configured recognizable theme colors for those users. This might not be the intent of the web designer, because all they wanted is a transparent scrollbar background and it would have been this spec alone to blame for screwing accessibility for those users.

Hover Effect

Whether intended by the spec or not - in Chrome's current implementation, specifying scrollbar-color also disables the hover effect on scrollbars. This is not only a general issue but also relevant in terms of accessibility. People with visual disabilities might rely on (or assissted by) the hover effect for knowing whether the mouse pointer is posiitoned on top of a scrollbar.

I don't think that the fault is on the side of the Chrome implementation, because well - which hover color should they be using? The choice (auto-calculation) could be wrong and it might be non-trivial to determine a universal algorithm for this, and then, we would also end up once again with having browser-specific implementation.

I rather think that this is a plot-hole in the spec.

Note that you cannot specify it like:

.scroller:hover {
  scrollbar-color: #000077 transparent;
}
.scroller:hover {
  scrollbar-color: #000099 transparent;
}

because that changes the color when hovering over the element rather on the scrollbar only (current behavior in Chrome).

Proposed Changes

1. Add Individual Color Properties

scrollbar-thumb-color
scrollbar-track-color

Each one can be specified individually or set to auto to get the default rendering.

2 Add Hover Color Property

scrollbar-thumb-hover-color

When not specified, defaults to scrollbar-thumb-color (disabling hover effects).

3 Redefine Current Syntax as Shorthand

To remain compatible with the preliminary implementations, the current notation can be redefined to be a shorthand like:

scrollbar-color: scrollbar-thumb-color scrollbar-track-color [crollbar-thumb-hover-color]

bramus commented 9 months ago

Cross-linking https://github.com/w3c/csswg-drafts/issues/9785 which also is about the scrollbar hover effect.

dianaqu commented 9 months ago

Hi,

Thanks for providing your feedback. The API is designed to be extendable to support new scrollbar styles that developers want. The currently supporting one is not transparent scrollbar, but more a windows style overlay scrollbar which is hidden when no user action and appears "transparent" when user is scrolling.

If you have more styles that you want to support, feel free to submit a feature request. If you have your own customized scrollbar style, I believe those can be achieved by CSS.

Your suggestions sounds like a different API, so feel free to make it as feature request as well and we will look into it.

softworkz commented 9 months ago

@dianaqu - Thanks a lot for your comment. Could it be that you rather wanted to respond my message in the WebView2 repository than here?

Feel free to hide your message here, than I'll do the same with this one. :-)

frivoal commented 9 months ago

I think the (main) part of this issue that discusses specifying a single color is a duplicate #5651. The part about a hover color is different though. The CSSWG prefers having one issue per topic and one topic per issue, to make it easier to track progress and to keep discussions easy to follow.

I would suggest:

adding to #5651 any information about single colors that's missing there.
opening a new issue about the hover color (tagged against level 2, as that would be a new feature)
Closing this issue

softworkz commented 9 months ago

think the (main) part of this issue that discusses specifying a single color is a duplicate #5651.

The essence sounds very different to this one:

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

II'm absolutely not suggesting this.

softworkz commented 9 months ago

But well, it seems it cannot repaired anymore for level 1? If the next version takes as long as this one, then there's not much point for me in engaging more on this. I just wonder how those mistakes (IMO) happened to be overseen even though it has gone over such a long time.

nstepien commented 8 months ago

For my use case, I want to make the scrollbar background transparent. That's it. This is because otherwise the scrollbar will overflow and will ignore border-radius. I don't want to guess what the other color should be, I want to use the default color. I wish I could use

  scrollbar-color: auto transparent;

but that does not work.

I'd also be happy if we could make the scrollbars respect border-radius and not overflow, without changing any scrollbar colors.

IMO making scrollbars a pseudo-element makes more sense 🤷‍♂️

frivoal commented 8 months ago

@nstepien see also https://github.com/w3c/csswg-drafts/issues/9853 for scrollbar-color and transparency

w3c / csswg-drafts