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

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

From: François REMY <francois.remy.dev@outlook.com>
Date: Sun, 24 Feb 2013 21:42:56 +0100
Message-ID: <DUB002-W32FE8BAACF16ED5BFF014FA5F20@phx.gbl>
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Simon Sapin <simon.sapin@kozea.fr>, www-style list <www-style@w3.org>
> Something that only accepted non-negative numbers wouldn't accept
> something typed as "number" - it'd need a "positive-number" type. Not
> too hard. 

Developers are going to like how verbose things will end up ^_^

> (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?

> > 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).

> > 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. 		 	   		  
Received on Sunday, 24 February 2013 20:43:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC