W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: [css3-variables] Fallback vs. "invalid at computed-value time"

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sat, 23 Feb 2013 16:16:42 -0800
Message-ID: <CAAWBYDBDQn+RYnOVq0=GmeOffR-6XSPFDL5L-OoX9ymqx2q+jg@mail.gmail.com>
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.

Received on Sunday, 24 February 2013 00:17:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:09 UTC