[css-properties-and-values-api] Resolved value of registered <color> custom properties.

[emilio]

The WPTs for this disagree on what the resolved value (getComputedStyle) of custom properties is when the computed value is currentcolor / color-mix() of currentcolor:

registered-property-computation.html says that it should return the value including currentcolor:

https://github.com/web-platform-tests/wpt/blob/efe3de7191/css/css-properties-values-api/registered-property-computation.html#L161

at-property-animation says that it should be resolved:

https://github.com/web-platform-tests/wpt/blob/efe3de7191/css/css-properties-values-api/at-property-animation.html#L440-L452

The computed value above is color-mix(in srgb, currentcolor, rgb(200, 200, 200)). Which one is it? Am I missing something? What is Blink / WebKit doing?

cc @flackr

[svgeesus]

It seems that it should be the value including currentcolor, so that it works correctly when inherited into child elements.

[emilio]

I agree the computed value should include currentColor, the question is whether getComputedStyle should resolve it (like it does for any non-custom color property)

[css-meeting-bot]

The CSS Working Group just discussed [css-properties-and-values-api] Resolved value of registered <color> custom properties., and agreed to the following:

• RESOLVED: <color> values returned by getComputedStyle() on standard CSS properties or registered custom properties is the used value
• RESOLVED: computed <color> values returned by TypedOM are the actual computed value

The full IRC log of that discussion

<jarhar> emilio: i recently noticed that what computed style returns for some properties is inconsistent. for most places it seems like tests expected the computed and not resolved color as any other color would.
<dbaron> ScribeNick: jarhar
<ChrisL> q+
<futhark> q+
<jarhar> emilio: but then ? expects some legacy rgb color result. i think we should decide on one. all engiens are exposing the computed and not resolve dcolor so if they did currentcolor and so on i think its fine to be doing that but i think it would be good to clarify that
<TabAtkins> +1 from me
<jarhar> ChrisL: i agree that they should do that. i see that mozilla made changes to wpt so that either is accepted as a pass. this is not a good situation. i think we should have a form that presserves currentcolor it means you get the right color instead of hard coding the color. i dont see why legacy rgb was accepted and why currentcolor should be
<jarhar> resolved so eagerly
<lea> +q
<lea> q+
<jarhar> emilio: this coudl be due to some animation implementation in webkit or blink but im not sure if blink and webkit actually interpolate including currentcolor like firefox does. if you interpolate curretncolora s asomething else then firefox will get the right behavior and im not sure if the others can do that but i think thats a bug in webkit
<jarhar> ChrisL: it would be good to ? from those implementors, firefox has donet he right thing while theres a spec ambiguity but id liek to hear if theres an objection to making the value be the one that includes currentcolor with color mix. i think thats the best one currently
<ChrisL> So color-mix(in srgb, currentcolor, rgb(200, 200, 200)) for example
<ChrisL> s/?/get feedback/
<jarhar> futhark: i can speak for blink. internally we should be using currentcolor inherit currentcolor. any other - if there are behaviors that are differnet that can be considered bugs. in computedstyle we always return the result color which is the used color that does not include currentcolor. our goal is to return currentcolor in the ?om api but we
<jarhar> currently dont do that but thats something we want to change
<emilio> q+
<jarhar> lea: chris you mnetnioedn that if we dont resolve currentcolor then that can be inerhited. is that the intent? i have come across cases where authors are registering custom properties as colors and then expecting it to resolve and inherit the textcolor of that element down to descendant rather than resolinv currentcolor the same was as you can
<jarhar> register a length asnd then set 1em as that and ?? expect it to resolve as colors
<jarhar> emilio: and that works the same anywhere
<jarhar> lea: there shouldnt be any special behavior for color mix ai agree
<futhark> q+
<jarhar> emilio: my understanding is that lbink actualy does return correct color from getcomputedstyle for these properties already. its just with animations where you dont
<jarhar> emilio: so if you look at the first link in the issue, the test does pass in blink and yeah it expects the getcomputedstyle value to not resolve, which is inconsistent with other color properties
<jarhar> futhark: i dont think thats intentional, or maybe it is when you do the interpolation im not sure if thats intentiona.,
<jarhar> emilio: i agree its weird which is why we should - im fine saying that we should always resolve them. i think we resolve them mostly for compat
<jarhar> futhark: i was looking at the spec and the cssom spec limits using the resolved value for certain colors but ? currentcolor not listed in the cssom spec. it would make sense for all colros to resolve for getcomputedstyle api and also be consistent with custom properties to do the same thing. that sounds like a consistent way for me. and then the
<jarhar> typedom return the current color version
<emilio> sgtm
<jarhar> fantasai: i believe we have a proposed resolution which is that getcomputedstyle returns a resolved color including custom registered properties
<jarhar> futhark: yes
<jarhar> ChrisL: but then its different in typedom? lets capture that
<emilio> q+
<jarhar> florian: so its not the used value and its not the computed value?
<jarhar> futhark: the cssom spec says that its the used value i think
<jarhar> florian: i think resolved is defined to be either the comptued or used depending onwhat it is
<jarhar> florian: the current proposed resolution is circular
<jarhar> fantasai: please type in a proposed resolution
<kbabbitt> q+ to rephrase the resolution
<jarhar> kbabbitt: im going to take a swing at rephrasing to say that the resolve dvalue fo ra registered custom proeprty of type color is the used value to be consistent with the used value of typed color on a non custom proeprty
<jarhar> fantasai: go further and include non standard properties
<jarhar> kbabbitt: that makes sense. and then in typedom we return the current value
<Zakim> kbabbitt, you wanted to rephrase the resolution
<fantasai> RESOLVED: <color> values returned by getComputedStyle() on standard CSS properties or registered custom properties is the used value
<jarhar> ChrisL: values in list of properties needs to be removed or ? or whatever. was it just removing that list?
<fantasai> RESOLVED: computed <color> values returned by TypedOM are the actual computed value
<jarhar> emilio: my other question is how would this animated value serialize. should it serialize with legacy rgb or the color function, but i guess this is somewhat - we could move this to a separate issue maybe
<ChrisL> It is related to https://github.com/w3c/csswg-drafts/issues/10087