W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-variables] Why we can not use 'var()' function for normal property

From: Marat Tanalin <mtanalin@yandex.ru>
Date: Tue, 02 Jun 2015 22:09:30 +0300
To: Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
Message-Id: <811141433272170@web24g.yandex.ru>
02.06.2015, 21:42, "Boris Zbarsky" <bzbarsky@mit.edu>:
> On 6/2/15 2:40 PM, Marat Tanalin wrote:
>> š02.06.2015, 21:36, "Boris Zbarsky" <bzbarsky@mit.edu>:
>>> šOn 6/2/15 2:29 PM, Marat Tanalin wrote:
>>>> šššIn your example, `a` and `b` are undefined since `c` is not specified.
>>> šEr, I meant, of course:
>>>
>>> šššššša: var(b);
>>> ššššššb: var(c);
>>> ššššššc: var(d);
>>> ššššššd: var(e);
>>> šššššše: color;
>> šThen values of `a`, `b`, `c`, `d` depend on what is `color` (as long as we have nesting-level limit greater than 5).
>
> Sure, but what if it's, say, 3? šDoes "a" have a value? šDoes "c"? šDoes
> it depend on whether "a" or "c" is computed first, or whether they're
> computed in parallel?

This depends on what property is accessed at a specific moment. Similarly, in JavaScript, if functions are calling each other, exact function that has started a call chain that has lead to achieving recursion limit depends on what function is called first. That's ok.

To be clear, limiting nesting level is not to get consistent results (though they would be in most cases as long as nesting-level limit is chosen reasonably enough big), it is just a possible trade-off to overcome rejecting an entire feature just on the basis of possible infinite loops. This does not necessarily mean though, that complete consistency is not achievable at all here (in particular, we could spec how, and in what order, to resolve all implicit relations between properties), just probably unneeded.
Received on Tuesday, 2 June 2015 19:10:06 UTC

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