- From: James Atherton via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Jul 2020 17:11:16 +0000
- To: public-css-archive@w3.org
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, https://github.com/w3c/csswg-drafts/issues/4075#issuecomment-601315813 this behavior looks unexpected even on the surface Further, [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. 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 -- GitHub Notification of comment by James0x57 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4075#issuecomment-665164097 using your GitHub account
Received on Tuesday, 28 July 2020 17:11:17 UTC