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:42:16 +0300
To: Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
Message-Id: <799941433274136@web25h.yandex.ru>
02.06.2015, 22:18, "Boris Zbarsky" <bzbarsky@mit.edu>:
> On 6/2/15 3:09 PM, Marat Tanalin wrote:
>> šThis depends on what property is accessed at a specific moment.
> So this requires either recomputing values or storing, with each
> property value, its "nesting depth", yes?

That's up to implementors.

>> š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.
> I don't think recursion limits in JS are a good model here. šThey vary
> by browser, by JIT heuristic, by operating system, and probably other
> things I'm not thinking of right now.

I've mentioned JS just for some extra clarity, not as an example or a proof. This may be omitted if needed.

>> šTo be clear, limiting nesting level is not to get consistent results
> Wait, stop. šWhy do we not want consistent results??? šWe do!

Sure. It's just a matter of what we want more: a limited feature with some possible inconsistency in edge cases, or no feature at all.

Actually, for the most part, nesting-level limit would serve just for spec editors to stop worrying about cycles while would not have negative impact to real-world web development in most cases.

By the way, we already have multiple inconsistencies in CSS, e.g.:

    * `@import` working only if used before any other rules;
    * `currentColor` using camelCase instead of hyphen-separated notation;
    * `:has()` available in the "Complete" profile, but not in the "Fast" one.

The latter serves for performance, the nesting-level limit I've proposed does too.
Received on Tuesday, 2 June 2015 19:42:47 UTC

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