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

On Sat, Feb 23, 2013 at 11:54 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 23/02/2013 20:32, Andrew Fedoniouk a écrit :
>>
>> Let's imagine that we have this rule:
>>
>> div {
>>    border: var(var1) var(var2) var(var3);
>> }
>>
>> Here we use variables that are not yet defined.
>> As at this point CSS parser has no knowledge about types of each variable
>> then
>> it cannot decide which "terminal" property will receive which variable.
>
> […]
>>
>> @variables {
>>     var1: 1px;
>>     var2: #ff0;
>>     var3: solid;
>> }
>
>
> Let’s get this out of the way first: there is no @variables rule at all in
> the current draft, but properties that cascade:
>
>   #something { var-foo: 1px }
>
>
> Usually, property declarations are "validated" against the property value’s
> grammar as soon as they are parsed. Invalid declarations are ignored, which
> lets you use fallback declarations such as:
>
>     background: #333;
>     background: linear-gradient(/* … */);
>
> Older browsers that do not support gradients will use the fallback’s solid
> color.
>
>
> This validation does *not* happen that early for declarations that use
> var(). It’s only at computed-value time (after the cascade), after var() has
> been substituted for the variable’s value, that the property value is
> parsed. A declaration can then be "invalid at computed-value time". This is
> exactly the same for shorthand as for longhand properties.
>
> To quote the draft:
>
> http://dev.w3.org/csswg/css-variables/#using-variables
>>
>> A variable is substituted for its value in the property value at
>> computed-value time. If a declaration, once all variables are
>> substituted in, is invalid, the declaration is invalid at
>> computed-value time.
>
>
> http://dev.w3.org/csswg/css-variables/#invalid-variables
>>
>> A declaration can be invalid at computed-value time if […] the
>> property value, after substituting its variables, is invalid. When
>> this happens, the computed value of the property is either the
>> property's inherited value or its initial value depending on whether
>> the property is inherited or not, respectively.
>
>
>
> Maybe the draft could do a better job at explaining that validation does
> *not* happen as it usually does before the cascade. (When shorthands are
> usually expanded.)
>

Hmm, interesting...

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.

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.

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?

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 23 February 2013 20:36:47 UTC