You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-scrollbars] Resolved value of scrollbar-color #3237
In the initial implementation of scrollbar-color in Gecko, I followed the way color properties are handled for gCS, basically according to the following sentence in CSSOM spec:
A resolved value special case property like color defined in another specification ... The resolved value is the used value.
But it is not clear to me whether this is actually useful at all, and should we make it follow other color properties to be the "special case" for gCS.
Although Gecko currently implements the "special case" way, i.e. auto is computed to two colors, I'm happy to make it not the case, because that's actually simpler. Also with the introduction of light and dark, maybe it makes sense to say auto doesn't necessarily mean two colors, so it shouldn't be resolved to two colors?
Anyway, I think this needs to be made clear in the spec one way or the other.
I think it's confusing for getComputedStyle not to return auto for scrollbar-color if that's what the specified value is. There's no real color value that is the used value here, if you are using native theming.
The CSS Working Group just discussed scrollbar styling, and agreed to the following:
RESOLVED: getComputedStyle() resolves colors same as other color properties, but other keyword values return as the keywrd
The full IRC log of that discussion
<fantasai> Topic: scrollbar styling
<fantasai> tantek: We did FPWD already
<fantasai> https://www.w3.org/TR/css-scrollbars-1/
<fantasai> heycam: Not sure who put this on the agenda, but I can make a demo if ppl want
<fantasai> tantek: we have an implementation in nightly
<fantasai> https://github.com//issues/3237
<fantasai> github: https://github.com//issues/3237
<fantasai> heycam: Question about what should happen with getComputedStyle() and the scrollbar color
<fantasai> heycam: Not sure we want to use resolved value
<fantasai> heycam: strange to have auto value become something else
<fantasai> heycam: would like to use the actual comptued value
<fantasai> dbaron: Is there a distinction between "auto or comptued color" and auto and used color?
<fantasai> emilio: We resolve computed color
<fantasai> heycam: I don't think we should resolve auto to a color
<fantasai> tantek: Also this is two colors, not just one
<fantasai> tantek: We had two properties, folded to one
<fantasai> tantek: Can also say if you want dark or light theme scrollbar colors
<fantasai> tantek: so not just a color property, a bit more complicated
<fantasai> fantasai: so if you specify a non-<color> keyword, return that keyword, otherwise return the same kind of resolved color as other color properties
<tantek> resolved colors (plural)
<fantasai> RESOLVED: getComputedStyle() resolves colors same as other color properties, but other keyword values return as the keywrd
<fantasai> heycam demos Firefo's implementation
<gregwhitworth> very, very cool heycam
<fantasai> tantek: Based on this implementation experience, we're pretty happy for light and dark for colors, and being able to specify colors
<fantasai> tantek: dark is interesting for web apps that have a dark theming regardless of what the OS theme is
<fantasai> tantek: Regarding width, having just thin vs not has been suficient for the use cases we've needed
<fantasai> tantek: we haven't implemented the <length> value and would be OK with dropping that
<fantasai> tantek: don't know if there are other implementers that have thought about this since Syndye
Activity
heycam commentedon Oct 23, 2018
I think it's confusing for getComputedStyle not to return auto for scrollbar-color if that's what the specified value is. There's no real color value that is the used value here, if you are using native theming.
css-meeting-bot commentedon Oct 23, 2018
The CSS Working Group just discussed
scrollbar styling, and agreed to the following:RESOLVED: getComputedStyle() resolves colors same as other color properties, but other keyword values return as the keywrdThe full IRC log of that discussion
<fantasai> Topic: scrollbar styling<fantasai> tantek: We did FPWD already
<fantasai> https://www.w3.org/TR/css-scrollbars-1/
<fantasai> heycam: Not sure who put this on the agenda, but I can make a demo if ppl want
<fantasai> tantek: we have an implementation in nightly
<fantasai> https://github.com//issues/3237
<fantasai> github: https://github.com//issues/3237
<fantasai> heycam: Question about what should happen with getComputedStyle() and the scrollbar color
<fantasai> heycam: Not sure we want to use resolved value
<fantasai> heycam: strange to have auto value become something else
<fantasai> heycam: would like to use the actual comptued value
<fantasai> dbaron: Is there a distinction between "auto or comptued color" and auto and used color?
<fantasai> emilio: We resolve computed color
<fantasai> heycam: I don't think we should resolve auto to a color
<fantasai> tantek: Also this is two colors, not just one
<fantasai> tantek: We had two properties, folded to one
<fantasai> tantek: Can also say if you want dark or light theme scrollbar colors
<fantasai> tantek: so not just a color property, a bit more complicated
<fantasai> fantasai: so if you specify a non-<color> keyword, return that keyword, otherwise return the same kind of resolved color as other color properties
<tantek> resolved colors (plural)
<fantasai> RESOLVED: getComputedStyle() resolves colors same as other color properties, but other keyword values return as the keywrd
<fantasai> heycam demos Firefo's implementation
<gregwhitworth> very, very cool heycam
<fantasai> tantek: Based on this implementation experience, we're pretty happy for light and dark for colors, and being able to specify colors
<fantasai> tantek: dark is interesting for web apps that have a dark theming regardless of what the OS theme is
<fantasai> tantek: Regarding width, having just thin vs not has been suficient for the use cases we've needed
<fantasai> tantek: we haven't implemented the <length> value and would be OK with dropping that
<fantasai> tantek: don't know if there are other implementers that have thought about this since Syndye
ewilligers commentedon Oct 25, 2018
outline-colorandcaret-colorare similar toscrollbar-color.Edge gives
invertas the initial computed value foroutline-color(consistent with spec) but Chrome/Firefox/Safari give rgb(...).upsuper commentedon Oct 25, 2018
That's because gCS returns resolved value, and resolved value of color properties are used value, not computed value.
tantek commentedon Jan 23, 2020
The CSS Scrollbars editor’s draft has an update to the Computed value for scrollbar-color of:
specified keyword or two computed colors
which reflects the above resolution as of 2018-10-23: #3237 (comment)
That just leaves adding it to the changes section.
(Originally published at: https://tantek.com/2020/023/t3/)