[csswg-drafts] [css-variables] Substitution of invalid variables into other variables (#5370)

James0x57 has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-variables] Substitution of invalid variables into other variables ==
In the spec it says to treat css variables as "unset" instead of "initial" if any compute results in the value becoming 'initial'.
(if the variable is directly set to `initial` without a compute, it behaves as `initial`)

<img src="https://user-images.githubusercontent.com/7545075/88717592-61cb7280-d0e6-11ea-9850-42b3730a3340.png" width="500px">


Until the most recent stable release of FF and Chrome, both browsers were ignoring this. #4075 


### I would like to have this wording changed to match the previous behavior of FF and Chrome:
> A declaration can be _**invalid at computed-value time**_ if it contains a var() that references a custom property with the guaranteed-invalid 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 the `initial` value, guaranteeing the [Guaranteed-Invalid](https://drafts.csswg.org/css-variables/#guaranteed-invalid) behavior.

### for the following reasons:
1. Standard properties with inheritance treat `initial` as sort of `unset`, except the behavior is "unset since the root". For example, see this demonstration on the inherited `color` property: https://developer.mozilla.org/en-US/docs/Web/CSS/initial

2. [the spec specifically says](https://drafts.csswg.org/css-variables/#invalid-variables) 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.

3. The behavior is confusing on the surface:
> ```css
>   code {
>     --color: red;
>   }
>   i {
>     --foo: initial;
>     --color: var(--foo);
>     background: var(--color, lime);
>   }
> ```
>   Background of `i` is `red` if it's nested inside of `code`, the expectation was `lime`

4. Since `initial` is the [guaranteed invalid behavior](https://drafts.csswg.org/css-variables/#guaranteed-invalid)
  > If, for whatever reason, one wants to manually reset a variable to the guaranteed-invalid value, using the keyword initial will do this.

  &nbsp;&nbsp;computing to `initial` to override a variable (and use fallbacks when referenced) should still be an option but is no longer possible. Now the guaranteed-invalid value is only guaranteed to behave the `initial` invalid value at the `:root` and is more of an edge-case than a guarantee we could rely on.

5. **Independent components can no longer be nested** (especially if they're two instances of the same component) if they use the same variables and rely on fallback behavior of var references `var(.., UNREACHABLE)`. (This is arguably the single most important reason the previous FF and Chrome behavior was very useful)


^ number 5 there should be a deal breaker for anyone wanting to make css-variables part of their library, even though the decision was recently made to follow spec, the decision had arguments on both sides, ultimately landing in a spot that removes a lot of possibility and readability from CSS variables.


Understanding the reasons listed here, especially num 5, I believe both @andruud and @emilio would agree that the behavior as it was before should be established as correct in the Spec and the browser changes be reverted. (& Safari should come along too)

Thank you for your consideration 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5370 using your GitHub account

Received on Tuesday, 28 July 2020 21:18:40 UTC