W3C home > Mailing lists > Public > www-style@w3.org > June 2014

Re: Cross Referencing Between Elements

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 11 Jun 2014 21:35:18 -0400
Message-ID: <539903D6.3020304@mit.edu>
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 

> The function is currently implemented as a vendor-prefixed `-moz-element()` function in Firefox [2]. How does the `element()` function deal with cross-referencing?


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.

Received on Thursday, 12 June 2014 01:35:49 UTC

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