- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Sat, 23 Feb 2013 22:38:10 +0100
- To: "www-style@w3.org" <www-style@w3.org>
Hi, I just realized that variables block the usual declaration fallback mechanism. I hope we can fix it. Since custom properties cascade, var() substitutions and thus syntax checking has to happen after the cascade. The current draft says: > A declaration can be invalid at computed-value time if […] the > property value, after substituting its variables, 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. In other words, the usual fallback mechanism does not work: var-bg: conic-gradient(/* … */); background: #333; background: var(bg); In an UA that does not support conic gradients, the background will be transparent (the initial value) rather than use the fallback solid color. This is unfortunate. The fallback mechanism is an important part of CSS. I think we could make it work with variables: This would mean having the cascade result in not just one, but an ordered list[1] of specified values for each (element, property) pair. Validation of values that use var() would still happen at computed-values time, but an invalid value is skipped for the next. The inherited or initial value is still there as a last resort. [1] Note: Implementations can skip values that have less "weight" that any value not using variables, as they will never be used. Is this something we could have in Level 1? If not, is there a risk of web content starting to depend on fallback *not* happening and thus prevent making the change in Level 2? -- Simon Sapin
Received on Saturday, 23 February 2013 21:38:36 UTC