- From: François REMY <francois.remy.dev@outlook.com>
- Date: Sun, 24 Feb 2013 21:42:56 +0100
- 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