-
Notifications
You must be signed in to change notification settings - Fork 645
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] Using scrollbar-color to tint the scrollbar #5651
Comments
One starting point to approach this, just to get the ball rolling, could be to use the provided color for the thumb and calculate the track color by keeping the same hue and changing lightness/saturation automatically until the desired contrast is found. In the first example above, the thumb would be In the second, the thumb would be This approach might not work in all cases, for instance with the |
What we recommended was slightly different: that each of the two color values also accepts the value
On a high level, yes. However, as with most things color, this is not as simple and straightforward as it sounds:
Footnote: Link to calculations |
Thank you very much for your detailed feedback, @LeaVerou I thought that there could be a way to define what would happen if only one color was provided to I like your proposal to use a keyword to indicate that a part's color should be automatically calculated by the UA. Do you want to open a separate issue for that? |
I don't think we should get into the details of specifying exactly how the browser computes the contrasting color. It should just do so, in a way that ensure good contrast, and how to do that is up to the UA. Also, do we want: |
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: single-color scrollbar-color<fantasai> github: https://github.com//issues/5651 <lea> sorry, was muted <TabAtkins> fantasai: so one thing discussed is whether scrollbar-color should accept a single color, auto-generating the second color from the first <TabAtkins> fantasai: another is around allowing 'auto' as a keyword in the two-value syntax, explicitly triggering auto-generation of the other color <TabAtkins> fantasai: We put it on the agenda to ask if there was interest in allowing this <emilio> I'd prefer not to add this unless there's strong author demand for it <Rossen_> q? <emilio> Not opposed per se but... <smfr> q+ <fantasai> lea: I think there should be some defined algorithm for UA to generate other color <fantasai> lea: reasonable for authors to define which color they want to alter, and UA to define other color <fantasai> lea: Would prefer that option rather than specifying only one color and having magic other color <fantasai> TabAtkins: ... <fantasai> lea: Should be possible to specify one color <fantasai> smfr: Wanted emilio to clarify, want single color to be invalid? <TabAtkins> s/.../note that the spec currently requires two colors, so we'd first have to agree to allow only one color before the rest becomes relevant/ <fantasai> emilio: So far, Firefox requires 2 colors, and I haven't seen anyone particularly complain about that <fantasai> smfr: I'm not opposed to a single color, but some ambiguity around whether lightening or darkening to generate the other color <fantasai> smfr: esp with dark mode <fantasai> smfr: might need to specify somehow <lea> q+ <TabAtkins> I'm on the side of "just have the author provide both" (aka no spec change), I think <Rossen_> ack smfr <fantasai> lea: wrt dark mode and whether UA darkens or lightens <fantasai> lea: that has to depend on the color as well <fantasai> lea: defined which direction to go, then what do you do when author specifies black? <fantasai> smfr: That's my point, there has to be a defined threshold where UA flips lightening vs darkening <fantasai> smfr: maybe dark mode is not relevant, mayb authors provide different colors <lea> q+ <Rossen_> ack lea <fantasai> lea: I think we're discussing minutiae of specifying a single color <fantasai> lea: but there's no consensus on whether this is desirable <fantasai> emilio: Same issue that smfr mentions is already a thing with accent-color <fantasai> emilio: Scrollbar-color already needs to synthesize other colors, e.g. for :hover effects <fantasai> emilio: If there's a strong desire to auto-generate track color... I'd rather not <fantasai> emilio: Authors might get what they want in some browsers and something different in other browser <fantasai> smfr: Ideal way to specify would be to just use color-5 functions <fantasai> smfr: Similar to ridge/groove <TabAtkins> Yeah, unlike accent-color, this is a place where we absolutely know where and how each color is going to be used. Auto-generating colors would be purely a convenience, not a necessity like in accent-color. <fantasai> s/groove/groove situation <fantasai> fantasai: main question is, do we want to do this or do we want to defer <fantasai> Rossen_: what's the consensus? <fantasai> smfr: I think it's nice to have, but fine to defer to scrollbars-2 <fantasai> emilio: same <fantasai> Rossen_: proposed to defer to l2, any objections? <fantasai> RESOLVED: Defer to L2 <fantasai> Rossen_: Encourage folks to engage on the issue and continue discussion there |
The property scrollbar-color from CSS Scrollbars allows the author to pass two colors, to be used by the thumb and the track of the scrollbar.
So,
scrollbar-color: indigo lavender
will produce a scrollbar where the thumb is#4B0082
and the track is#E6E6FA
.The spec also advises authors to "ensure the specified colors have enough contrast between them".
I don't know if this has been discussed previously, but what should happen if only one color was provided to
scrollbar-color
?My proposal is that when one color is provided to
scrollbar-color
, it would be used by the UA to automatically define the color scheme for the scrollbar (to "tint" it, so to speak).This would allow authors to easily style the scrollbars on their pages while the UA ensures adequate accessibility by making sure that the specific colors have enough contrast between them.
The text was updated successfully, but these errors were encountered: