- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 02 Apr 2008 14:04:41 -0500
- 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. True. > 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. -Boris
Received on Wednesday, 2 April 2008 19:05:35 UTC