[css-color-4] Make system color keywords compute to themselves

[tabatkins]

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.

[upsuper]

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]

Either that or we wouldn't support interpolation between system colors.

[heycam]

Or we have special rules to define that animations between colors use their resolved values.

[svgeesus]

Or we have special rules to define that animations between colors use their resolved values.

That seems preferable, given the whole forced colors thing.

[svgeesus]

So we need to update css-color-4 to say that they compute to themselves, but that their resolved value is an rgb value

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]

Any impacts regarding animations also affect currentColor as an interpolation end point, since currentColor is 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).

Or we have special rules to define that animations between colors use their resolved values.

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]

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 keywords

The 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