[css-scrollbars][css-scrollbars-1] Can we simplify to two scroll-*-color properties?

[tantek]

Can we simplify from seven scroll-*-color properties to just two? (roughly equivalent to foreground/background, stroke/fill)

It appears that scrollbar-face-color and scrollbar-base-color are used either directly for or as input in determining the other colors if the other colors are not set.

We should experiment to see if we can satisfy most use-cases with just two scroll-*-color properties.

In addition, real world examples (see Bugzilla 77790) appear to typically use just two colors (but repeat them across the seven properties).

Can we use those examples to help determine just which two properties we need for the 80/20?

(expressed by @upsuper and @smfr)

Update: tracking examples and which properties / unique colors they use here:

• https://www.w3.org/wiki/Css-scrollbars#Use-cases

[tantek]

The flow of which properties auto-set which others, from http://www.howtocreate.co.uk/tutorials/scrlbar.html we can derive these:

• scrollbar-base-color vvv

  • scrollbar-3dlight-color
  • scrollbar-face-color
  • scrollbar-highlight-color
  • scrollbar-shadow-color
  • will also turn scrollbar-darkshadow-color black if it is not already (OS dependent)

• scrollbar-face-color and scrollbar-highlight-color vvv

  • scrollbar-track-color

Unspecified (where it comes from)

• scrollbar-arrow-color

[nt1m]

See my comment in #1956 (comment)

[craigkovatch]

Here is our real-world product example that would not be possible with the paradigm being discussed here. (This is in Stylus, please let me know if any of the syntax isn't clear.)

// Chrome + Safari
::-webkit-scrollbar {
  width: 6px;
  height: 6px;
  border-radius: 1px;
}

::-webkit-scrollbar-track {
  border-radius: 1px;

  :hover& {
    background-color: $grey_2;
  }
}

::-webkit-scrollbar-thumb {
  border-radius: 1px;

  :hover& {
    background-color: $grey_4;
  }

  &:hover {
    background-color: $grey_6;
  }

  &:active {
    background-color: $grey_7;
  }
}

[mstange]

I'm in favor of simplifying the list of proposed properties to remove any Windows 95-isms. But I don't think a single fill color and a single stroke color is enough. At the minimum we need the ability to specify a different color on hover, and the ability to use rounded endcaps instead of square endcaps.

[upsuper]

I've implemented scrollbar color properties on Windows and macOS in Firefox, and so far there are only two properties necessary: scrollbar-face-color and scrollbar-track-color.

(Windows implementation has landed behind a pref, while macOS one is still pending on review.)

The following are screenshots from my implementation:

The custom one are done with the following declarations:

.custom {
  scrollbar-face-color: lightblue;
  scrollbar-track-color: azure;
}

.custom {
  scrollbar-face-color: #2e4359;
  scrollbar-track-color: #1b2836;
}

This is simple to use and native to platforms.

I think we can remove everything else from the list at this point.

[craigkovatch]

Strongly, but respectfully, disagree. The web's current use of the existing -webkit-scrollbar* along with a number of "custom scrollbar" libraries suggests it's not this simple. Designers want border radii, they want hover colors, they want to be able to change dimensions. We don't do the web community any favors writing a new "standard" that doesn't fulfill its needs.

[jonjohnjohnson]

I think just these two properties could be good enough, if they allow for colors with a transparent alpha value, for browsers that allow the track to "overlay" the content. And if using scroller styling is spec'd to not inhibit other native system ui, such as losing the whole scrollbar fading in/out on MacOs in chrome when using it's current custom styling properties. I'm mostly concerned about the familiarity side of usability here.

If people want to break further from the users expectations of system scrolling, I figure they can always do something like... https://developers.google.com/web/updates/2017/03/custom-scrollbar

[upsuper]

The basic idea behind doing the scrollbar properties approach (rather than the pseudo-element approach) is for giving browsers leeway to render what they think is most sensible for users while still addressing popular usecases required by authors like scrollbars in dark mode / theme / compact.

And yes, authors can always create different style of scrollbars with HTML elements especially, and with Web Components they can be well encapsulated. There can be way more creative way for scrollbars for specific web apps which can never be done with pseudo-element approach either.

This approach is focusing on provide simple and native way to help authors address basic usecases without much effort to deal with platform specific details (which pseudo-element approach is specifically bad on, e.g. scrollbar shape, buttons, etc.).

[craigkovatch]

To me the most critical issue to address is making scrolling visually customizable without affecting the behavior at all. Scrolling is one of the most viscerally important human-computer interactions. We all get muscle-memory accustomed to whatever scrolling behavior is afforded by one's hardware + OS, and it's very important to user experience and expectation that the browser doesn't try to mess with this. To this end, it's important we don't just say "well if you need more, make a custom scroller" -- because that most often ends with a component that looks good but doesn't feel right, and in a very aggravating way.