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

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
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 2 April 2008 13:22:29 UTC