Repository navigation
[css-color-4] Make system color keywords compute to themselves #3847
Description
In order to make system colors reflect the color-scheme, which can change throughout the tree, we need these colors to be able to inherit as keywords whose used value can change depending on color-scheme. (For Web-compatibility, however, they will need to still have a resolved value of a particular rgb value.) So we need to update css-color-4 to say that they compute to themselves, but that their resolved value is an rgb value.
Activity
Pass used color-scheme to SystemColor.
Store keyword for unresolved StyleColor.
Make color-scheme affect used system color.
[css-color-4] Add computed/used entry for system colors, linking to #…
upsuper commentedon Oct 30, 2019
It sounds this would make color animation more complicated. You may need to be able to express a computed color like
10% currentcolor + 20% Canvas + 30% Text + ... + 5% red, which... doesn't sound fun.heycam commentedon Oct 30, 2019
Either that or we wouldn't support interpolation between system colors.
heycam commentedon Oct 30, 2019
Or we have special rules to define that animations between colors use their resolved values.
svgeesus commentedon Oct 30, 2019
That seems preferable, given the whole forced colors thing.
svgeesus commentedon Oct 30, 2019
That seemed straightforward to me when I first read this issue, and was about to just add it (but I hadn't considered animation when I thought that)
AmeliaBR commentedon Oct 30, 2019
Any impacts regarding animations also affect
currentColoras an interpolation end point, sincecurrentColoris also spec'd to compute/inherit as a keyword. All browsers currently support animating currentColor, as far as I know, so we can't break that. Firefox also successfully inherits it as a keyword, even when animating, but Chrome (and I think WebKit) do not.Test: https://codepen.io/AmeliaBR/pen/VwwMEqy?editors=1100
Note that, in Firefox, the inherited background color on the div animates between currentColor and tan, even though it has a different currentColor (hotPink) than the parent which defines the animation (alternating navy and red).
I'm not sure how this would work for the cases in the demo, where the reference colors change during the animation, and where the animated value is inherited.
I'd rather just jump ahead and introduce an interpolation function to describe the intermediary computed state of
interpolate(50%, currentColor, tan).css-meeting-bot commentedon Oct 30, 2019
The CSS Working Group just discussed
Make system color keywords compute to themselves, and agreed to the following:RESOLVED: Make system color keywords behave like currentColor and inherit as keywordsThe full IRC log of that discussion
<dael> Topic: Make system color keywords compute to themselves<dael> github: https://github.com//issues/3847
<dael> TabAtkins: Back in the day system colros could become rgb at computed value time. Now that we can switch user themes using color-scheme you can turn it on and off at subtree. That changes what system colors resolve to
<dael> TabAtkins: Thus they should act like currentColor
<dael> TabAtkins: Talked to our impl and it's fine
<dael> chris: Issue about animation, but can animate currentColor
<dael> AmeliaBR: Don't have interop on currentColor
<dael> AmeliaBR: As far as making system color keywords inherit as keywords we want them same as currentColor. We just need impl to go through details of making currentColor and these inherit as keywords
<dael> AmeliaBR: Right now FF does it. Chrome and I think WK do not
<dael> TabAtkins: Chrome appears to. I tested yesterday. We're doing it sufficiently close to look correct in a test
<dael> AmeliaBR: DOesn't when you animate or you're newer chromium version
<dael> TabAtkins: Might be jsut passin gmy straightforward test
<tantek> interesting, thought we had enough currentColor tests to get interop. curious about the test cases that demonstrate non-interop
<fantasai> dbaron, getComputedStyle would return a resolved color
<dael> AmeliaBR: Complexities with animations; if we still agree currentColor spec is right those same rules would apply to making system colors inherit as keywords
<dael> chris: Makes sense to me
<dael> myles: Does that mean fingerprinting is no longer necessary?
<dael> TabAtkins: Nope because they always show as rgb in gCS
<dbaron> s/fingerprinting/fingerprinting stuff we just resolved on/
<dael> TabAtkins: THat's hard compat requirements, people have been relying on it
<dael> chris: Need animation on current and system colors?
<dael> TabAtkins: Sure
<AmeliaBR> s/animation/animation tests/
<dael> AmeliaBR: With the cavaet that we need more tests, any obj to making system color keywords behave like currentColor and inherit as keywords?
<tantek> inherit as keywords makes sense to me
<dael> RESOLVED: Make system color keywords behave like currentColor and inherit as keywords
<fantasai> +1, we need this for them to behave correctly in the presence of forced-color-adjust / color-scheme
fantasai commentedon Oct 30, 2019
Fixed in 1263778 however there's an open question of how the deprecated system colors should be handled; tagged that to #3873.
upsuper commentedon Oct 30, 2019
So what's the solution for animation? I think Firefox and Chrome both support transition with currentcolor (as far as I tested previously), not sure what is non-interop here. Requiring to animate resolved value would certainly break that. Not sure whether that's important, though.
AmeliaBR commentedon Oct 30, 2019
The solution for animation is "do what Firefox does for currentColor", at least as far as rendering goes.
But you're right: when it comes to serialization / TypedOM representation of the mid-animation computed value (not resolved value), I think we do still need a syntax for describing the interpolation between two keyword computed color values.
Maybe that should be a new issue?
upsuper commentedon Oct 30, 2019
What I meant to say in #3847 (comment) is that Firefox's approach is not scalable to more keywords. It was done under the assumption that only
currentcolorwould behave that way. It's not touching serialization / Typed OM, but about the fact that animating with multiple parts which can change during animation could be challenging.But I might be wrong because most complexity of animating
currentcolorcomes from the fact thatcoloritself can animate as well, so there might be some smart way to handle all the system color keywords which can only discretely switch (AFAIU) without adding too much complexity to implementation, but I'm not sure.Serialization / Typed OM is indeed something we need to consider, but I don't think that has or would introduce inherent complexity as far as we allow only linear combination of colors and keywords. But animation may have such complexity by itself.
upsuper commentedon Oct 31, 2019
Hmmm...
colorcan have system color keyword as well... That may or may not make the situation more complicated...Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-awa…
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-awa…
style: Make Canvas/CanvasText and Link colors color-scheme-aware
style: Make Canvas/CanvasText and Link colors color-scheme-aware
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-awa…