New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
tantek opened this Issue Nov 8, 2017 · 15 comments

Comments

Projects
None yet
6 participants
@tantek
Contributor

tantek commented Nov 8, 2017

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:

@tantek

This comment has been minimized.

Contributor

tantek commented Nov 10, 2017

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

tantek added a commit that referenced this issue Nov 14, 2017

likely reduction in properties to 2-3 per research
likely reduction in properties to 2-3 per research, link issue #1960 and research so far, encouragement for contributions
@nt1m

This comment has been minimized.

nt1m commented Nov 16, 2017

See my comment in #1956 (comment)

@craigkovatch

This comment has been minimized.

craigkovatch commented Dec 15, 2017

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;
  }
}

image

@mstange

This comment has been minimized.

mstange commented Jun 14, 2018

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

This comment has been minimized.

Member

upsuper commented Jun 26, 2018

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:
Custom scrollbar colors on Windows
Custom scrollbar colors on macOS

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

This comment has been minimized.

craigkovatch commented Jun 26, 2018

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

This comment has been minimized.

jonjohnjohnson commented Jun 26, 2018

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

This comment has been minimized.

Member

upsuper commented Jun 26, 2018

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

This comment has been minimized.

craigkovatch commented Jun 26, 2018

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

This comment has been minimized.

jonjohnjohnson commented Jun 26, 2018

@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

This comment has been minimized.

nt1m commented Jun 26, 2018

@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

This comment has been minimized.

Member

upsuper commented Jun 26, 2018

@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

This comment has been minimized.

nt1m commented Jun 26, 2018

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

@craigkovatch

This comment has been minimized.

craigkovatch commented Jun 26, 2018

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

tantek added a commit that referenced this issue Jul 4, 2018

reduce to two properties, -face-color -track-color
Per #1960 (comment) implementation/prototyping experience, reduce number of properties to two: scrollbar-face-color and scrollbar-track-color. Resolves issue #1960
@upsuper

This comment has been minimized.

Member

upsuper commented Aug 30, 2018

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

@upsuper upsuper closed this Aug 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment