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

On Wed, Apr 2, 2008 at 12:06 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>  Henri Sivonen wrote:
>
> > Allowing app code to index into platform structures that are most commonly
> forward-iterated seems like an anti-pattern in terms of what implementation
> constraints are placed if the impression that the app developer gets is that
> indexing has the performance properties of array access and that it is OK to
> write app code with that assumption.
> >
>
>  AS you noted in another post, in practice app developers assume that
> anything they do will be fast and when it's not they blame the UA.  And
> therefore, no matter which access pattern you expose it has to be fast.
>

Having an unsync'd or "non-live" list would be fine, except for one
fact: This would be inconsistent and would require the introduction of
a new interface, call it StaticNodeList, for example.

OTOH, If the  - childElements -  property returns a NodeList, it would
be more consistent with the other parts of the dom.

childNodes is a NodeList
childElements is a NodeList

Providing a NodeList offers simple and consistent way to solve the
problem of dealing with unwanted text nodes.

Script authors can use slice.call on a live NodeList to get a static
snapshot, if desired. If this could be accomplished in the DOM, even
better, but it would be inconsistent to have a StaticNodeList for
childElements a NodeList everywhere else. It would seem better to
either use only NodeList, or introduce StaticNodeList as an alternate
option for NodeList everywhere.

My .02

Garrett

>  -Boris
>
>

Received on Thursday, 3 April 2008 05:23:13 UTC