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

On Sat, Feb 23, 2013 at 1:07 PM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> 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.

You didn't get my point.

For this declaration:
div {
     background: #333;
     background: linear-gradient(/* … */);
}
you said the following:

If UA does not support linear-gradient() it will use
     background: #333;
, correct?

Now let's consider this declaration for the UA that supports
variables but not gradients :

var grad1 = linear-gradient(/* … */); /* it is set somehow */

div {
     background: #333;
     background: var(grad1);
}

on this you said the following:

As UA supports variables then it will use
     background: var(grad1);
declaration. But as the UA does not support
gradients (or the var value just invalid)
then it will use background: transparent;

Is all this correct in your opinion and how it
should work?

Personally I would expect that this

div {
     background: #333;
     background: var(invalidvar);
}
will end up with background color set to #333.
That's if we want to keep status quo and
make variables as a dynamic alternative to
current static declarations.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Sunday, 24 February 2013 02:28:13 UTC