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: Mon, 25 Feb 2013 17:39:51 -0800
Message-ID: <CAAWBYDBQkmBbB0gV4UbP7V=ZeEx9AS7HBi_ORwynwdBvWAtRbg@mail.gmail.com>
To: Fran├žois REMY <francois.remy.dev@outlook.com>
Cc: Simon Sapin <simon.sapin@kozea.fr>, www-style list <www-style@w3.org>
On Sun, Feb 24, 2013 at 12:42 PM, Fran├žois REMY
<francois.remy.dev@outlook.com> wrote:
>> (And all property names should be valid types as well, so
>> most of the time you can just use the name of the property you're
>> going to substitute the variable into.)
> It would be awesome! Did you check if that works? I mean, isn't there a risk that a valid type become a valid property name at some point?

Unlikely.  You know we're allergic to short names here in the CSSWG.
^_^  Using the basic names defined for attr()'s types - "integer",
"number", "length", "angle", "time", "frequency", "string", "url", and
"color" - none but the last seem likely to become CSS properties.  The
last luckily works fine as both a type and a property name.

>> > selector {
>> > background: var(bg1, var(bg2));
>> > /* not only buggy but also dangerous:
>> > even if bg1 works, if bg2 fails
>> > then the entire rule is dropped */
>> > }
>> Incorrect. From the spec: "If the variable named by the first
>> argument is valid, the variable's value is substituted as normal. If
>> it's invalid, and a <fallback> was provided, the <fallback> is
>> substituted instead. Otherwise, the variable is an invalid variable."
>> The fallback isn't even touched unless necessary. An invalid "bg2"
>> variable won't have any effect as long as "bg1" is valid.
> Just to be sure: you mean that variable replacement is an iterative process so that not all property references are resolved at the same time (ie: if a reference is in a fallback path and that fallback path isn't evaluated, it is never resolved and therefore never 'used'?). If yes, we're on the same wave on this one ;-)
> However, that doesn't seem very clear (to me, at least) in the spec: it just says that if you happen to 'use an invalid variable' in a declaration, it's marked invalid-at-computation-time. Still that kinda makes sense, I mean: you don't really 'use' a property reference if it sits in an 'unused' fallback value. It would probably be good to clarify the 'used' definition (btw, this is completely editorial, but I noted there are some 'can' used at spots where 'must' should be used instead).

Good point.  I'll see what I can do to make this clearer.

>> > selector {
>> > background: var(shadow-host button-background, green);
>> > background: var(shadow-host button-background, conic-gradient(...));
>> > }
>> I don't understand the problem here, nor your example since it uses an
>> unfamiliar syntax.
> Sorry, I can't refrain from using next-gen features, just remove shadow-host and you'll be all right ;-) What I meant is that there's still no easy way to fallback the fallback value.

Right.  You can, however, use a second typed variable, and just
fallback to that.

Received on Tuesday, 26 February 2013 01:40:40 UTC

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