- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 25 Feb 2013 17:39:51 -0800
- 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. ~TJ
Received on Tuesday, 26 February 2013 01:40:40 UTC