- 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