W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

Re: [Element Traversal LC] access to element by index

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 02 Apr 2008 14:04:41 -0500
Message-ID: <47F3D8C9.5090301@mit.edu>
To: Henri Sivonen <hsivonen@iki.fi>
CC: "Web APIs WG (public)" <public-webapi@w3.org>

Henri Sivonen wrote:
> I'm not claiming it would be awfully hard, but it does change the impact 
> of Element Traversal from adding four or five methods on an existing 
> class (mere code footprint; super-simple)

That depends on what performance characteristics callers expect or UAs want to 
provide.  More on that below.

> And then, there are issues like should childElements return 
> the same object every time.


> And if yes, then the implementor needs to 
> add a new pointer to each element node or to add a hashtable on the 
> owner document or something along those lines.

Assuming there is nothing like that in place already, yes.  I guess I'm a little 
biased since in Gecko there is somethign like that in place already (if nothing 
else to support setUserData() from DOM3 Core).  One could also allow UAs to 
choose, of course, but that might give them different performance 
characteristics.  But you can't prevent that anyway; see below.

> And to what end? To use indexing instead of list-style iteration.

This is the really good question.  The other major use-case of an actual object 
that represents the list of child elements is that the script can cache the 
object if it intends to iterate the list multiple times.  That, of course, 
raises questions about whether the list should be live or not, because for 
different use cases one might want to cache one or the other.

If the common envisioned use case for this will involve multiple iterations of 
the list, possibly separated in time, then the right performance tradeoff might 
be creating an object which caches the list of child elements so as to avoid 
having to walk all the non-element kids and check their types all the time.  The 
caching could happen in the user script, or it could happen in the UA itself. 
The latter is what I'm guessing would end up being implemented in Gecko given 
the spec as it stands.  I say that because I strongly suspect that, in practice, 
child elements of the same node are walked multiple times.

Note that any use case that involves getting the childElementCount immediately 
means that two walks are required on the UA side, by the way.

Received on Wednesday, 2 April 2008 19:05:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC