[css-variables] Computed value of custom property referring invalid custom property

[upsuper]

In wpt, there is a test doing this check:

<style>
  #target10parent {
    --varA: good;
    --varB: Also good;
    --varC: another good one;
  }
  #target10 {
    --varA: var(--varB);
    --varB: var(--varA);
    --varC: var(--varB);
  }
</style>
<div id="target10parent">
  <div id="target10"></div>
</div>

It is clear that --varA and --varB should be empty (invalid) for #target10 because they form a loop. But what should be the computed value of --varC on #target10 here?

The test thinks it should be empty, and all current impls (I tested Firefox without Stylo, Chrome, Edge, and Safari) agree on that. Servo didn't agree with this, and compute --varC to inherit the value from #target10parent, so we got another good one. (This was fixed in servo/servo#18660)

Although we change Servo's behavior to match other impls, it seems that Servo's previous behavior actually matches what the spec says. Specifically, in this case, --varC declaration in #target10 should be "invalid at computed-value time", and per spec,

When this happens, the computed value of the property is either the property’s inherited value or its initial value depending on whether the property is inherited or not, respectively, as if the property’s value had been specified as the unset keyword.

Given that custom properties are inherited, it seems that --varC should really inherit the value rather than being empty in this case.

As all impls agree on the other behavior, and we already have test for that, we probably should change the spec to reflect that, unless people have other opinion. It seems to me that the current behavior (resetting when invalid for custom properties) is both simpler in impl and more intuitive.

[upsuper]

cc @SimonSapin

[FremyCompany]

I think the reason the "invalid" behavior was implemented is that otherwise you can get funny results like:

body { --color1: red; --color2: yellow; }
body > div { --color1: var(--color2); --color2: var(--color1); }
body > div > span { color: var(--color1); background-color: var(--color2); }

where the order in which you decide to "give up" and use the inherited value has an impact on the final result; though another valid solution would be red text on yellow background I guess, out of curiosity what did Servo used to do in that case?

[upsuper]

In the case you mentioned, both --color1 and --color2 should be invalid in span, and thus color would be inherit and background-color would be initial, which is unambiguous.

Servo used to have a different behavior only when a custom property which is not in any loop itself, but refers to such invalid custom property.

[FremyCompany]

In the case you mentioned, both --color1 and --color2 should be invalid in span, and thus color would be inherit and background-color would be initial, which is unambiguous.

What I would have expected. So, based on that, I agree we should just clarify the spec to match the test.

[tabatkins]

Ah, this ends up being a dupe with #5370, which we resolved by spec edits. The spec now mandates the requested behavior - --varC isn't involved in the cycle, but it attempts to use --varB (which is involved, and thus is IACVT) without a fallback, so it becomes IACVT as well and just resets to its initial value (the guaranteed-invalid value).

[tabatkins]

(I know this one came first, but the other one had more significant discussion, so this is the one that gets marked as a dupe.)