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

On Tue, Jun 2, 2015 at 10:37 AM, Marat Tanalin <mtanalin@yandex.ru> wrote:
> 02.06.2015, 19:45, "Tab Atkins Jr." <jackalmage@gmail.com>:
>> On Tue, Jun 2, 2015 at 9:27 AM, Marat Tanalin <mtanalin@yandex.ru> wrote:
>>> Instead of fearing cycles at all, we could just limit nesting/recursion
>>> level for `var()`, so that once some reasonable limit (e.g. 10)
>>> is achieved, applying styles referenced by corresponding nested `var()`
>>> calls is just stopped.
>>
>> there's no "recursion".  CSS is declarative, not imperative; there's no defined evaluation order.
>
> On implementation level, _there is_ an evaluation order anyway. Exact order is not necessarily should (or even must not) be described in a spec, it should be enough just to spec a specific limit.

Evaluation order affects what things hit the limit, and when.  It is
not acceptable to have unspecified behavior for something like this,
particularly when the behavior is very likely to vary across
implementations, or even within a single implementation (if the order
depends on hash-table ordering, for example, which might not be stable
across pages using similar styles).

Also, what Boris said.

> For example, the spec could say:
>
> "If there are more than 10 nested `var()` calls,
>  then all involved properties must be ignored."
>
> For example, if we had a specced/implemented nesting limit of 3 (exact number of 3 would probably too small in practice and is used just for code-example brevity), then with this CSS code:
>
>     a: var(b);  /* #1 */
>     b: var(c);  /* #2 */
>     c: var(d);  /* #3 */
>     d: var(e);  /* #4 */
>
> an implementation would stop the "recursion" on `var(e)` since it is 4th `var()` in the `var()` chain. In another implementation, evaluation order could be different, but the result should be the same -- once nesting-level limit is reached, reading the chain is stopped and all properties in the chain are ignored.

This appears to give identical results to just doing cycle checking,
except that it breaks cases that are otherwise well-defined (if --e
was a keyword or something, your example would be perfectly legal and
work fine).  This does not solve the problem.

Nothing that suggests doing anything about var() itself will solve the
problems I listed, because they're about the *implicit* dependencies
between properties, not explicit ones introduced by var().

~TJ

Received on Tuesday, 2 June 2015 18:08:56 UTC