1492040 - Maybe implement light/dark value of scrollbar-color

Status: NEW

(Core :: CSS Parsing and Computation, enhancement, P5)

Description

[Xidorn Quan [:xidorn] UTC+10]

These values were added mostly for patent coverage, but we may still want to implement this if authors feel this is useful.

Some implementation notes:

On the style system side, we need to create a new type StyleScrollbarColor, maybe something like
struct StyleScrollbarColor
{
  enum Tag { eAuto, eLight, eDark, eColors };
  Tag mTag;
  StyleComplexColor mThumb;
  StyleComplexColor mTrack;
};

On the widget side, for Cocoa, we should rename ScrollbarParams::onDarkBackground to something like useDarkVariant, and have scrollbar-color affect it when its value isn't "auto".

Windows support dark mode natively but we don't seem to be using dark scrollbar when that is enabled, which may be fine in general, but we may want to investigate how to render the dark variant. If there isn't such API, we may need to use the custom scrollbar path with the color observed from native apps.

For Linux we would almost certainly need to use the custom scrollbar path (the fallback path) whenever the value is not "auto".

Comment 1

[Florens Verschelde :fvsch]

We used scrollbar-color in DevTools to avoid jarring colors in the DevTools light and dark themes. On Linux this means we get the fallback design, which is close to what we were doing in the dark theme (using JS-based fake floating scrollbars).

In bug 1471163 we are getting feedback from Linux users that this is undesirable, and they would prefer keeping the GTK scrollbars, especially when the GTK scrollbars fit their accessibility needs better.

> For Linux we would almost certainly need to use the custom scrollbar path (the fallback path) whenever the value is not "auto".

Could it be possible instead to use the light/dark keywords to request the light or dark GTK subtheme for the currently selected theme? Basically we leave it to users to use a GTK theme with provides both light and dark variants.

That would be the ideal solution for DevTools IMO, because it would fix our design issues (at least on modern distros with default settings) while allowing users to have a choice, and also avoid making DevTools look like a foreign element in the Firefox UI.

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

> Could it be possible instead to use the light/dark keywords to request the light or dark GTK subtheme for the currently selected theme? Basically we leave it to users to use a GTK theme with provides both light and dark variants.

If there is such API provided by GTK, then I guess we should use that.

Comment 3

[Mick P.]

https://bugzilla.mozilla.org/show_bug.cgi?id=1608663 could use a "chrome" value to get back legacy behavior in regard to recent (72) bullshit changes to monkey with the scrollbar colors.

Transparent backgrounds are given a light recolor bar... maybe if FF is going to keep recoloring the scrollbars it should at least investigate the backgrounds behind iframes so it doesn't switch between colors.

The scrollbar is on the margin of a window or monitor and doesn't need to reflect the webpage. As it's on the margin its colors should be based on OS level Dark/Light theme settings. In that case choosing "light" and "dark" just further breaks things. Make Dark OS setting a queryable state in the DOM. Quit monkeying around. Who wants to set Night Modes at more than one level?

Comment 4

[Luke Warlow]

The light and dark keywords have been removed from the spec: https://github.com/w3c/csswg-drafts/issues/6438. It would be more desirable IMO to honour the color-scheme property/meta tag. This is how Chrome and I believe Safari handles light and dark theme scrollbars.

Comment 5

[Tantek Çelik]

Agreed with Luke. These keywords have been dropped from the spec so we shouldn’t implement. I suggest we close this as WONTFIX.