[csswg-drafts] [css-scrollbars] Flaws in the Spec for `scrollbar-color` (#9826)

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

== [css-scrollbars] Flaws in the Spec for `scrollbar-color` ==
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 I've read somewhere in the discussion).

This is quite untrue, I'm afraid. 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 (a UA may be configured to to have 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 on 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 different 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 thems 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 great 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:

- https://github.com/MicrosoftEdge/WebView2Feedback/pull/4221#issuecomment-1902167622
- https://groups.google.com/a/chromium.org/g/blink-dev/c/PkEsMirl2zE/m/A23Z7-GmBwAJ


### Accessibility Concerns

In the spec design, accessibility concerns have been given as an argument for requiring both color values to be provided - or none.
The given reasoning behind 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 the 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. You cannot specify it like:

```css
.scroller:hover {
  scrollbar-color: #000077 transparent;
}
.scroller:hover {
  scrollbar-color: #000099 transparent;
}
```
because this 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]`








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


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

Received on Saturday, 20 January 2024 18:29:33 UTC