[css-scrollbars] Resolved value of scrollbar-color #3237
Comments
|
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
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 |
|
Edge gives |
|
That's because gCS returns resolved value, and resolved value of color properties are used value, not computed value. |
|
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/) |
In the initial implementation of
scrollbar-colorin Gecko, I followed the way color properties are handled for gCS, basically according to the following sentence in CSSOM spec: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.
autois computed to two colors, I'm happy to make it not the case, because that's actually simpler. Also with the introduction oflightanddark, maybe it makes sense to sayautodoesn'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.
cc @tantek
The text was updated successfully, but these errors were encountered: