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