W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 2 Apr 2008 22:22:40 -0700
Message-ID: <c9e12660804022222v484ddf8cifcc3580dc4c75ef0@mail.gmail.com>
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: "Henri Sivonen" <hsivonen@iki.fi>, "Web APIs WG (public)" <public-webapi@w3.org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 3 April 2008 05:23:14 GMT