- From: François REMY <francois.remy.dev@outlook.com>
- Date: Thu, 6 Dec 2012 11:11:33 +0100
- To: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
I've an issue with this proposal. I know that this is mostly what the current specification says, but I would prefer the validation algorithm of Token Stream References to match the one of Attribute References. That means that I would like the fallback value to be valid (or un-specified) in order for the declaration to be valid. I also would like to be able to bring Attribute References type converter on all kind of references (probably in L2). My current proposal is: "If the fallback value of a reference is not a valid instance of its reference type, the declaration that contains the reference is invalid at declaration time (and should therefore be ignored). An expression containing references is also invalid at declaration time if, when all references it contains providing a fallback value have been replaced by their fallback value, it's impossible to find any valid value for the remaining references that can make the resulting expression valid where it is used." So, this would discard at parse-time: - background: get(x-a || 3px) // 3px is not a supported value for background - color: red get(x-a) // a <color> cannot be divided in two <value> tokens - background: get(x-a | color | url('...')) // url('...') is not a color The reason I propose this change is to make sure authors don't loose the possibility to "branch" properties easily in CSS rules when they use variables: * { background: red; background: x-gradient(...); } may get refactored into * { background: get(x-main-color || red); background: get(x-main-bg || x-gradient(...)); } but it won't work anymore on browsers that do not support x-gradient (following the current rules). However, I agree it's possible to refactor that in another way if you have dynamic validation type for properties; I would more king on agreeing to be less strict on fallback value if we give authors the possibility to write things like: * { background: get(x-main-bg | supports background | get(x-main-color || red)); } or alerternatively * { background: first-of(get(x-main-bg), get(x-main-color), red); } ---------------------------------------- > Date: Wed, 5 Dec 2012 23:25:28 -0800 > From: dbaron@dbaron.org > To: www-style@w3.org > Subject: [css-variables] parse-time error handling in uses of variables > > I recently noticed a relatively major omission in > http://dev.w3.org/csswg/css-variables/ : it doesn't say anything > about the or the error handling for *uses* of variables. > > In particular, declarations that use variables in the value are > preserved for later variable substitution, at which point either the > variable substitution works or the declaration is invalid at > computed-value time. > > However, the specification doesn't define which declarations get > preserved until computed value time for this process to happen. > > I'd like to propose that this preservation (and the resulting > cascading) should happen for any declaration (of any property) that: > (a) meets all the syntactic requirements for the value of a > variable property > (b) contains at least one "var(" function token > (c) has every "var(" function token followed (through the matching > ')' token) by syntax that is a valid var() function in this > level of the specification > > > For example, this would mean that: > background: red; > background: var(undefined-variable); > would produce a transparent background, as would: > background: red; > background: var(undefined-variable, bad fallback syntax); > but that: > background: green; > background: var(undefined-variable, bad fallback syntax, > third argument not in this level of CSS); > would produce a green background since the second declaration would > be thrown out because of point (c). > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla http://www.mozilla.org/ 𝄂 >
Received on Thursday, 6 December 2012 10:12:15 UTC