- From: <keshlam@us.ibm.com>
- Date: Mon, 28 Feb 2000 18:35:30 -0500
- To: www-dom@w3.org
> DOM allows me to access a childNode directly by using the item(index) > method > off of the nodelist that is returned from childNodes, rather than walking > the nodelist. > > So, I was expecting that if I had the reference to the childNode, it would > have an index property that I would be able to use for routines like this, > rather than having to examine the nodelist itself. > > Am I really expecting too much? :-) You're expecting a particular implementation. In some implementations, a node does indeed have an index property within its parent. But others only know who their parent and immediate siblings are; to get their index, they would have to walk the sibling chain, "counting on their fingers". It might be more efficient to instead walk until you either find the other sibling or fail to find it, and just return that relative positioning rather than absolute. Note that the general case of relative positioning of two nodes is harder; you have to determine the lowest common ancestor, then determine which one comes earlier. And you have to deal with the case where there _isn't_ a common ancestor... and decide whether to report attributes that way, or as falling between their owning Element and its children... while remember that either way, the attributes are officially unordered relative to each other. Remember, NodeLists are not necessarily implemented as arrays of nodes. They're live filtered views of the document which just happen to be integer-indexed to make them easier to use for folks who think in terms of arrays. But they're arguably more closely related to the DOM Level 2 NodeIterator and TreeWalker than to a simple array. ______________________________________ Joe Kesselman / IBM Research
Received on Monday, 28 February 2000 18:36:42 UTC