Skip to content
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] Resolved value of scrollbar-color #3237

Closed
upsuper opened this issue Oct 23, 2018 · 5 comments
Closed

[css-scrollbars] Resolved value of scrollbar-color #3237

upsuper opened this issue Oct 23, 2018 · 5 comments

Comments

@upsuper
Copy link
Member

@upsuper upsuper commented Oct 23, 2018

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.

cc @tantek

@heycam

This comment has been minimized.

Copy link
Contributor

@heycam heycam commented 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

This comment has been minimized.

Copy link
Member

@css-meeting-bot css-meeting-bot commented 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 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
@ewilligers

This comment has been minimized.

Copy link
Contributor

@ewilligers ewilligers commented Oct 25, 2018

outline-color and caret-color are similar to scrollbar-color.

Edge gives invert as the initial computed value for outline-color (consistent with spec) but Chrome/Firefox/Safari give rgb(...).

@upsuper

This comment has been minimized.

Copy link
Member Author

@upsuper upsuper commented Oct 25, 2018

That's because gCS returns resolved value, and resolved value of color properties are used value, not computed value.

@tantek

This comment has been minimized.

Copy link
Member

@tantek tantek commented 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/)

@tantek tantek closed this in 8b12bb3 Jan 23, 2020
@tantek tantek removed the Needs Edits label Jan 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.