Re: [css-variables] and shortcut properties, fundamental limitation?

Le 23/02/2013 21:36, Andrew Fedoniouk a écrit :
> But what should happen if you have, say, this:
>
> div {
>     background: #333;
>     background: linear-gradient(/* … */);
>     background: var(c1);  /* #1 */
>     background: var(grad1); /* #2 */
>     background: var(url1) var(repeat1); /* #3 */
> }
>
> And in run-time any of mentioned variables may have invalid values.
> So at any given moment of time one or all prop defintions 1..3
> can be invalid.

What do you mean by "run-time"?

As explained in the previous email:
In a browser that supports css3-variables, any property declaration that 
contains var() is not validated as usual when parsed. In this case the 
last one would win the cascade. The specified value is "var(url1) 
var(repeat1)". Then var() are substituted for their own computed values. 
At this point if the result is invalid, the initial value of background 
(transparent) will be used.

It is a design limitation of css3-variables to prevent the use of 
fallback declarations.

For the definition of specified and computed value:
http://dev.w3.org/csswg/css3-cascade/#computed


> At the moment in CSS each terminal property can contain
> just one value, so two property declarations:
> div {
>    background-color: #rgb1;
>    background-color: #rgb2;
> }
> are parsed into single background_color variable of type color.
> Later one simply overrides first one.

Again, I’m not sure what you mean. Does "terminal property" mean "not 
shorthand"? (Like 'background' is a shorthand for the 'background-*' 
properties?)

Among declarations for the same property in the same rule, the last that 
is valid wins. css3-variables do not change that, only that any 
declaration that uses var() is considered valid for this purpose. 
(Validity is checked later.)


> As far as understand css-variables require change
> of underlying storage for properties. Particular property value
> storage shall accept now list of value and variable references rather
> than single value.
>
> Therefore to get computed value of a property UA will need
> to check each variable in the list for validity.
>
> In short: without variables CSS rules can be compiled in parse
> time into binary structures (for effective access).
>
> But CSS variables mandate CSS declarations to be interpreted
> each time when CSS rule matches the element.
>
> It's quite substantial architecture limitation, no?

I think you have some misconceptions on how the cascade works, or at 
least are not using the right terminology. If you want to read more, 
this might help:

http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

I’m not sure of the details of what you mean, but on the high level: 
Yes, css3-variables requires rather profound changes in implementations 
(if only because there is an unbounded number of variables, instead of 
just a finite set of properties,) but nothing that can’t be managed. So 
far none of the browser vendors has objected on that front. Some of them 
even have experimental implementations.

As to the storage of variable values during the cascade, yes it is an 
unparsed list of tokens.

-- 
Simon Sapin

Received on Saturday, 23 February 2013 21:07:42 UTC