[css-variables] Substitution of invalid variables into other variables

[andruud]

A declaration can be invalid at computed-value time if it contains a var() that references a custom property with its initial value, as explained above, or if it uses a valid custom property, but the property value, after substituting its var() functions, is invalid. 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.

I have found nothing in the spec that says the above does not apply to custom property declarations themselves. If I'm not mistaken, this means that the following:

<style>
  #outer { --y:foo; }
  #inner { --y:var(--x); }
</style>
<div id="outer">
   <div id="inner"></div>
</div>

... will for #inner produce a computed value foo for --y. This is because --y is an inherited property, and per the spec text above the value is treated as unset.

Chrome and FF currently treat --y as the 'invalid at computed-value time'-value, and we have WPT that verify this seemingly incompliant behavior.

Is my interpretation of the spec correct? If yes, do we change the spec or fix WPT?

[AmeliaBR]

I think you're right that the current behavior / WPT aren't matched by the spec, which would treat your second rule equivalent to #inner { --y: unset; }.

The following paragraph makes a custom property invalid if it uses var() references with invalid grammar:

In addition, if the value of a custom property contains a var() reference, the var() reference must be valid according to the specified var() grammar. If not, the custom property is invalid and must be ignored.

But, the example you gave has valid grammar, it is only invalid at computation time.

Changing the spec to match implementations & tests would be the easiest course of action. So the question is, what is the cost of doing that?

What use cases are prevented by the current behavior? Is it confusing for authors (e.g., when working with Houdini APIs) that custom properties behave differently from regular properties in this case?

[andruud]

I think it would "only" cost us consistency. Can't think of any use-cases that would be limited (either way).

Your intuition is right that this adds confusion in the Houdiniverse; there has been at least one report of confusion, though here it probably doesn't help that I've implemented registered custom properties to work per spec, which adds another de-facto inconsistency with (the actual implementation of) unregistered custom properties.

Personally, I think we should at least try to change browser behavior. I'm mostly fishing for whether there's a hidden CSSWG resolution / TPAC hallway discussion / Tab Atkins tweet / hivemind consensus that custom properties should work the way they actually do in browsers, and it just never reached the spec, or whether this was just an unlucky oversight during the creation of some WPT.

[FremyCompany]

Interesting problem, thanks for reporting it.

(fwiw I'm in favor of getting browsers fixed for this case if there is support for that; based on what I know I assume that wouldn't be hard and would improve consistency, especially for houdini scenarios as noted before)

[tabatkins]

The spec does indeed say that #inner should get --y value of "foo".

I'm ambivalent about which direction we fix this in, but if following the spec makes the rest of ecosystem more consistent, then we should try and fix browsers (and the tests) to follow the spec. I do like when we can keep custom properties more in line with normal properties.

[emilio]

It'd be unfortunate to treat this case differently from the case where the custom properties are cyclic, where right now the spec says that they compute to the initial value rather than unset.

[tabatkins]

Ah, good point. I made that behavior different from just being straight invalid on purpose; staying invalid rather than silently inheriting a value from higher up in the tree seemed like a better behavior for authors in the case of a cyclic reference, which is a straight-up error that needs fixing.

On the other hand, more generally, I want invalid-at-computed-value-time to act as close to invalid-at-parse-time as possible, thus the "unset" behavior.

So I suppose what happens to specifically custom properties that are iacvt could be argued in either direction.

What should happen to registered custom properties that are iacvt? They're intended, as much as possible, to act like "real" properties; presumably then they should use the "unset" behavior, right?

I also generally want unregistered properties to act like registered ones when possible, to reduce the chance of a surprising behavior change. So that suggests custom properties should stick with the specified "unset" behavior, right?

I'm happy to hear arguments to the contrary on any of these points. ^_^

[andruud]

Perhaps css-variables should name the concepts invalid-at-computed-value-time and cyclic-at-computed-value-time, if we're keeping the distinction. Looks like the spec is currently saying:

• invalid-at-computed-value-time ➜ unset
• cyclic-at-computed-value-time ➜ guaranteed-invalid

What should happen to registered custom properties that are iacvt?

IMO the same thing that happens to unregistered custom properties that are iacvt (whatever the behavior is). And registered custom properties that are cacvt should probably have the same behavior as the unregistered cacvt case.

They're intended, as much as possible, to act like "real" properties; presumably then they should use the "unset" behavior, right?

Yes. 👍

I also generally want unregistered properties to act like registered ones when possible, to reduce the chance of a surprising behavior change. So that suggests custom properties should stick with the specified "unset" behavior, right?

Also yes. 👍

I think it's fine to keep the current distinction between iacvt and cacvt, if that's what we want. Although, for registered custom properties + cacvt we have to pick between consistency with standard properties (unset) and consistency with custom properties (guaranteed-invalid). Should be the latter, IMO, since the cyclic aspect is more strongly associated with custom properties.

Making both iacvt & cacvt behave as unset would make everything consistent, but then cyclic errors could be more annoying for authors. (Not sure if the error detection for cycles is very important to authors in practice, though ...)

[tabatkins]

This makes sense to me.

So the implications are:

1. Cyclic references cause all the involved (directly participating in the cycle) properties to become the guaranteed-invalid value, whether they're registered or unregistered. (Because this is in all cases an error.)

2. All other cases cause invalid-at-computed-value-time, and resolve to "unset", regardless of whether it's a normal property, a registered custom property, or an unregistered custom property. This implies that, in your original example, the #inner --y should have a value of foo.

Right?

[andruud]

Right?

Right! :-) And that behavior is already defined by the spec as-is (I think). Though it might be good to be a bit more clear on the distinction between iacvt and cyclic.

Related bonus information worth keeping in mind: standard properties can also participate in a cycle, but they can't be "guaranteed-invalid", so they'll have to get unset in both iacvt and the cyclic case. This slightly "pollutes" the otherwise clean separation between iacvt and cyclic, unfortunately ... not a huge deal, though.

[tabatkins]

Hmmm, I forgot that they can indeed participate in cycles.

Them being guaranteed-invalid wouldn't do anything anyway; you can't substitute them in, which is the only case where guaranteed-invalid does anything anyway.

So okay, I'll make this clearer in the spec, and write a wpt for it (unless you already have one ready?).

[andruud]

write a wpt for it (unless you already have one ready?).

We do have WPTs for this, but they currently verify the wrong thing (hence this issue in the first place). You don't have to make a test; I'll adjust the tests we already have. :-)

[tabatkins]

Okay, I pushed some changes defining "cyclic at computed-value time" and making "invalid at cvt" hopefully more clear. I also dfn'd "guaranteed-invalid value", the initial value of custom properties, so it can be referred to more easily (I already referred to it in the P&V spec, it's just a broken link right now until the spec processor cycles around!).

[emilio]

I'm still not quite sure I agree with the behavior here being more similar to "invalid-at-parse-time", if you have multiple declarations for the same custom property, for what is worth.

[tabatkins]

Can you elaborate on what you mean?

[emilio]

I mean that if you have:

#foo-parent {
  --bar: inherited;
}
#foo {
  --bar: something-valid;
  --bar: var(--invalid);
}

I'm not sure my expectation would be that --bar on #foo is inherited.

[tabatkins]

Yeah, there's limits on how close we can get, definitely. Thus "as close as possible".

The general principle is to make registered custom properties act more like built-in properties when possible, and make unregistered act like registered when possible, to reduce the overall cognitive load. Built-ins can grammar-check at parse-time and get richer error recovery (falling back to the previous value in the cascade), which custom properties aren't capable of. But if you force a built-in property to delay grammar checking until computed-value time (by using a var() in it), then if it violates its own grammar it becomes unset; thus registered properties should ideally do the same.

And yeah, I do think that cyclic properties becoming the guaranteed-invalid value to help in realizing errors is a better behavior, despite it technically being a behavior difference from built-ins. Built-ins can only go cyclic amongst themselves in rare cases ('em' in font-size, %s in sizing properties sometimes, etc), and handle it in bespoke ways, so there's no consistent behavior to start from, and adding another bespoke error behavior isn't making the situation any worse than it already is. ^_^

[JaneOri]

https://bugs.chromium.org/p/chromium/issues/detail?id=1110188

This decision seems like it was heavily considered in both directions since it's contradictory in one interpretation. I would really really really appreciate a re-evaluation of where it landed though because the consequences have entirely removed the ability to have a --css-variable component be nested with itself and use fallback behavior in var(...) references (they also cannot be nested with other independent components relying on a same-named variable now)

And just as @emilio presented, #4075 (comment) this behavior looks unexpected even on the surface

Further, the spec specifically says that the cascade value should be thrown out by the time it's become invalid at computed-value time:

Note: The invalid at computed-value time concept exists because variables can’t "fail early" like other syntax errors can, so by the time the user agent realizes a property value is invalid, it’s already thrown away the other cascaded values.

Also, initial is interpreted as "unset anywhere" for everything else, for example:
https://developer.mozilla.org/en-US/docs/Web/CSS/initial
This demonstrates that color, which is also inherited, when set to initial becomes black because it behaves as unset since the root, essentially skipping its inherited behavior.

This change has made the "guaranteed invalid" behavior of css variables into an edge case only guaranteed on :root

cc @andruud @tabatkins

[tabatkins]

Hm, looking at your referenced test case in the bug, it seems like a somewhat unrelated issue to this thread.

What you're seeing is just the fact that a property becoming iacvt makes it unset (aka inherit or initial, depending on whether the property inherits or not). In your examples, the child's --c property becomes iacvt (because it references another custom property which is iacvt due to using the guaranteed-invalid value), and thus it switches to its inherited value, which is the red it gets from the parent element.

And just as @emilio presented, #4075 (comment) this behavior looks unexpected even on the surface

Emilio's comment doesn't look relevant here, either - he's saying that in his example, the variables behavior doesn't act like "drop invalid properties" (since we can't actually do parse-time dropping). But in your example, it does look exactly like dropping an invalid property - if you pretend the child's --c is invalid and dropped at parse time, then you'd see exactly the behavior you're getting, where the parent's --c declaration inherits down to the child.

---

It sounds like what you're wanting is for the guaranteed-invalid value to be preserved as it's substituted thru custom properties, so that the iacvt behavior of making the value unset only triggers on "real" properties (or perhaps on registered custom properties as well), and you can trigger fallback at any point in a variable chain (rather than only at the exact point where the guaranteed-invalid value is introduced). Is this right?

This isn't an unreasonable request! In w3c/css-houdini-drafts#994 (comment) Amelia asks for the ability to explicitly allow a registered property to still assume the guaranteed-invalid value, which is currently only possible when you have a completely unrestricted grammar. Implicitly, this is recognizing that the guaranteed-invalid value actually is "valid" in some circumstances; it's guaranteed to never match the grammar of any predefined CSS property, but it's part of the value space (and thus, matches the grammar) of unregistered custom properties, or registered ones with unrestricted grammar.

This is a different choice than what we've currently made in the spec, but it's not a wrong one. And I think I've talked myself into preferring it. It would be a minor behavior change, tho. @andruud, any thoughts?

[tabatkins]

Actually, I'm taking this over to #5370; reclosing this issue.