[css-ui] Computed value of currentColor

[frivoal]

css-ui-3 defines the computed value of caret-color this way:

The computed value for auto is auto. For values, the computed value is as defined for the [CSS3COLOR] color property.

The intent was (among other things) to have currentColor compute to currentColor as a keyword, but it is not clear if this wording is good to unambiguously define it that way.

In css-color-3, we're told that:

The used value of the ‘currentColor’ keyword is the computed value of the ‘color’ property. If the ‘currentColor’ keyword is set on the ‘color’ property itself, it is treated as ‘color: inherit’.

The first sentence says that currentColor is resolved at used value time, which implies that it stays as a keyword at computed value time. “treated as” in the second sentence implies that at computed value time on the color property, currentColor has been replaced with the computed value of the color property on the parent element.

Despite the fact that CSS-UI invokes the computed value logic of the color property, it wouldn't make much sense for currentColor on caret-color to “be treated as inherit”, but it would be possible to read it as currentColor being replaced by an actual color value at computed value time. Given that caret-color is an inherited property, this would lead to a different (undesirable) behavior than preserving it as a keyword at computed value time.

css-color-4 also agrees. It says the following about currentColor:

if the value is inherited, it’s inherited as currentcolor, not as the value of the color property, so descendants will use their own color property to resolve it.

Since the intended meaning in css-ui-3 and the meaning inferred by color-4 agree: currentColor should computed to currentColor as a keyword. I suggest making this unambiguous in css-ui-3 by changing the Computed Value entry in the propdef table to:

The computed value for auto is auto, and for currentColor is currentColor. For other values, the computed value is as defined for the color property.

[frivoal]

Agenda+. I expect this to be completely uncontroversial, but it is a change to a CR, so a group decision is warranted.

[frivoal]

WG was in favor of this, but wanted a better wording that could more easily be reused across specs that have the same issue. That wording should be anchored on definitions / alogrithms / rules / etc found in level 3 of the color spec. If necessary (e.g. the wording we want is in level 4 or not written yet) we can make errata to color 3.

[tabatkins]

The idea is some simple algorithm that can be invoked akin to the "lengths made absolute" wording used by tons of properties with inherited lengths, so we don't have to call out special cases in every single property that uses colors.

[frivoal]

AFAIK, the closest we have now is the second sentence of https://drafts.csswg.org/css-color-4/#currentcolor-color

[frivoal]

That simple algorithm should probably also be the place where we put the answer to #480. Don't know if the level 3 version of that algo should do that much or if that should be left to level 4, but that seems like the right hook.

[frivoal]

I've made a tentative pull request to add the the anchoring terminology and definition in https://github.com/w3c/csswg-drafts/pull/871

[frivoal]

@svgeesus

As discussed at the Seattle F2F, there is some overlap between https://drafts.csswg.org/cssom/#serialize-a-css-component-value and the definition introduced by #871.

871 is more specific / clear about which color should resolve to what at what time, but cssom is more specific about how to serialize the various functions once you've decided to do that.

Fixing this redundancy by having css-color-4 just keep the high level logic, and defer to cssom for the string level details of how to serialize the value does not seem particularly good to me, as presumably the new functions added to css-color-4 (and later) will have their serialization in css-color-4 (and later), and then you need to look up to multiple specs to have the full picture.

What I think would be nicer is:

• inline the the details that currently live in cssom into css-color-4
• have css-color-4 normatively state that it supersedes cssom on this topic
• leave cssom as is, so that more mature specs along TR that refer to it and don't want to switch css-color-4 can keep on doing so (and maybe add a note informatively pointing back to color-4).

The remaining question is then how to port that back to css-color-3, which I think we need to for two reasons:

• what css-color-3 says about color computed values and serialization is inaccurate and contradicts level 4 / cssom / implementations
• specs like CSS-UI which wants to refer to this just need the anchoring terminology, not the new color functions, and for TR progress purposes would rather depend on color-3 (which is a REC) than color-4 (which is an ED).

The easiest way to do that is to duplicate the level 4 definition, simply omitting references to notations that don't yet exist in level 3. But I am not sure what that means in terms of process. Is an errata enough? do we need to cycle back to CR/PR/REC? Errata sound sufficient for correcting the serialization, but not for introducing the new anchor terminology.

[frivoal]

On further toughts, and having checked https://www.w3.org/2013/09/normative-references, I don't think the referencing problem is actually a problem. Yes, css-color-4 is much less mature than css-color-3, but the rules about normative references do not forbid it, and given the guidelines it spells out for evaluating whether a dependency is ok or not, we can easily make the case that it is fine.

So, since #871 has been merged and the relevant part of it (currentcolor computes to currentcolor) is stable, I can refer to it from css-ui.

I'll close this issue with a commit doing just that, and move the rest of the previous comment to a separate issue.