On Apr 2, 2008, at 15:09, Jonas Sicking wrote:
It can be a pain to add IDs to *all* the nodes you ever access. A
pattern i've seen a lot is to have small repeating sections in a
page, and then navigating within that repeated section.
That makes sense.
That said, I don't think there's a problem with having a
getChildElementByIndexThisIsNotGuaranteedToBeArrayAccess() if you
really want to get the nth element child only instead of iterating
with an index.
Sure, as long as we also
add .firstElementChildThisIsNotGuaranteedToBePropertyAccess ;)
Hmm. Somehow I thought it would be a given that nextElementSibling/
firstElementChild wouldn't be direct pointers but convenience getters
built on top of nextSibling and firstChild. But I guess an app
developer might as well expect the DOM to maintain lots and lots of
direct pointers...
Anyway, myFooElement.getChildrenByTagName("*")[3] looks like it does
something more expensive than myFooElement.childElements[3] even if
the implementation were the same, so they give app developers
different expectations of performance characteristics.
The same argument can be made for .nextElementSibling, why give
forward-iterating access into platform structures that are most
commonly index-accessed?
Indeed the argument I made should lead to iterator objects instead
of either item(n) or nextSibling.
I think one of the major design flaws of the DOM is that it gives
two views to the tree without specifying the performance
characteristics of those views. App developers who like linked
lists may reasonable assume that nextSibling is a mere pointer
dereference. App developers who like arrays may reasonably assume
that item(n) is a mere array access. Now DOM implementations are
damned either way and have to do tricks to make the non-native view
fast as well.
Honestly, is this really a big problem? It used to be that iterating
a child list using .nextSibling was O(N^2).
It was a problem for me when I tried to walk the HTML5 spec in Firefox
1.5 using iterative traversal with firstChild/nextSibling/parentNode.
Firefox 1.5 performed a *lot* worse than the then-current versions of
Opera and Safari. And the spec was a lot smaller back then, too. :-)
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
