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

[jonjohnjohnson]

@craigkovatch If you check the google developer article I linked to, it shows a custom, yet "native" nyan cat scrolling example, which hopefully all browsers eventually support. I'd guess this addresses your concern for the feel of scrolling? I'm more concerned with a happy path of styling a scroller that is visually familiar for user experience, especially when I keep in mind many of my visually impaired friends relying on an accessible web.

[nt1m]

@upsuper What if a platform decides in the future that scrollbars are no longer flat, and no longer use two colors ? That's well possible because it was the case in the past.

[upsuper]

@nt1m browsers may try to derive the colors from the specified colors. Actually you can see that in my current implementation, there are already several colors derived from the two colors in the UI, including the arrow on Windows and the border on macOS.

[nt1m]

@upsuper I'd love to see how this works out for Windows 7 aero scrollbars :)

[craigkovatch]

@jonjohnjohnson I'd love to understand more about how you think visual familiarity of scrolling is important to visually impaired friends.

Incidentally, I also have a significant visual impairment, and have spent the better part of the last two years working professionally on web accessibility. That's probably why I care so much about scroll experience -- I spend a lot of time zoomed in. Wrt to my own impairment I couldn't care less about how scrollbars look -- but I want web designers to have a full set of styling tools available so that nobody is ever tempted to re-implement scrolling. I think scroll experience is a fundamentally "intimate" human-computer interaction and whatever the user is used to shouldn't be mucked with. But if we don't give a full suite of styling tools (ala -webkit-scroll*), we incentivize re-implementation instead. That's a much more unfortunate path.

I'm not saying the old webkit properties ought to be standardized, there's some significant ambiguity to them. But only providing color properties seems woefully insufficient.

[upsuper]

Close as it has been simplified to two colors in the current draft.

[craigkovatch]

@upsuper this is an unfortunate and upsetting response. This issue has active discussion and lacks consensus. Codifying a standard before that consensus is achieved -- and now having Firefox 64 implement that draft -- ignores the issues that have been raised here. This is not the way the web is supposed to work.

[astearns]

@craigkovatch incremental progress is one of the ways 'the web is supposed to work'. Specifying two colors now does not prohibit us from adding more capabilities in the future.

[craigkovatch]

@astearns It absolutely prohibits an entire class of additional capabilities in the future -- because it assumes the issue to solve is "native scrollbars need some minor adjustments" rather than "scrollbars should be design-able like any other web element".