- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 02 Apr 2008 02:44:17 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, "Web APIs WG (public)" <public-webapi@w3.org>
Henri Sivonen wrote: > > On Apr 2, 2008, at 00:48, Boris Zbarsky wrote: >> OK. So item() would be available on Element after casting it to >> NodeList in those implementations. I guess you're saying that the >> cast would not longer be unambiguous if there were multiple NodeLists >> that might make sense? So childElements couldn't be implemented with >> a |return this;|? >> >> That doesn't seem like such a terrible implementation burden to me, to >> be honest... > > > 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) to adding more run-time object > instances. 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. Again, not awfully hard, > but still more complex than just adding convenience methods on an > existing class. Sure it's more complex, but it's still trivial. > And to what end? To use indexing instead of list-style > iteration. Exactly. Something that I would imagine is quite commonly done. Note that we're not just talking iterating over a full DOM tree, we're also talking about navigating around in a DOM tree from one known specific node to another. / Jonas
Received on Wednesday, 2 April 2008 09:45:23 UTC