- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 11 Jun 2014 21:35:18 -0400
- To: Marat Tanalin <mtanalin@yandex.ru>, Brian Blakely <anewpage.media@gmail.com>
- CC: "www-style@w3.org" <www-style@w3.org>
On 6/11/14, 5:19 PM, Marat Tanalin wrote: > What does browser when there is cross-referencing of functions in JavaScript? > > It throws an error: But that's simple: JavaScript has a concept of time flow and entry points which CSS doesn't have. > I have no idea why there is so much fear about cross-referencing in CSS compared with JS. Because the two are conceptually very different. CSS doesn't have a model of "you start here, then you do this thing, then this next thing" like JS; it has the typical declarative constraint model of atomic updates to the entire state of the world. So it's a lot harder to do sane (read performant) handling of cross-referencing recursion issues in CSS. That said, the fear is not even about cross-referencing but about proposals that involve cross-referencing but don't define the resulting behavior. > The function is currently implemented as a vendor-prefixed `-moz-element()` function in Firefox [2]. How does the `element()` function deal with cross-referencing? http://dev.w3.org/csswg/css-images/#element-cycles which is basically what SVG uses for paint servers cross-referencing each other, as far as I can tell. It's not what -moz-element() does, fwiw; that does some sort of rendering and render-time detection of cycles, so it will still render what it can and prune out the cyclic bit. But, and this is important, both SVG paint sources and element() are limited to ID lookups. These are very fast and more importantly easy to keep track of dynamically because browsers already keep track of an id-to-element(s) mapping to make things like getElementById() fast. There's a memory cost here, but it's a sunk cost. Furthermore, dynamic changes to the value of the id attribute are fairly rare, so all you really have to worry about in practice is updating on insert/remove operations in the DOM, and only for elements which have an id. On the other hand, if you allow arbitrary selectors in this sort of setup then either you have to use a bunch more memory tracking which selectors currently map to which first element (so you can update when that changes) or you spend a bunch of time computing which elements are matching or no longer matching on DOM mutations. It's doable, but it'll cost a bunch of memory or CPU time or both. -Boris
Received on Thursday, 12 June 2014 01:35:49 UTC