- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sat, 23 Feb 2013 16:16:42 -0800
- To: Simon Sapin <simon.sapin@kozea.fr>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Sat, Feb 23, 2013 at 1:38 PM, Simon Sapin <simon.sapin@kozea.fr> wrote: > 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: Correct. The entire concept of "invalid at computed-value time" was introduced specifically to handle this case without having to remember multiple values in the cascade. In other words, the fact that the fallback mechanism doesn't work is intentional. > 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? As I said above, implementors purposely didn't want multiple cascaded values, so this is the intended effect for level 1. It is likely that authors will end up depending on this property, at least accidentally, and so we wont' be able to change it in the future. ~TJ
Received on Sunday, 24 February 2013 00:17:28 UTC