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