W3C home > Mailing lists > Public > www-style@w3.org > February 2013

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

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Sat, 23 Feb 2013 20:54:57 +0100
Message-ID: <51291E91.6030808@kozea.fr>
To: Andrew Fedoniouk <news@terrainformatica.com>
CC: "www-style@w3.org" <www-style@w3.org>
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:

> 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.

> 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.)

Simon Sapin
Received on Saturday, 23 February 2013 19:55:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC