- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 2 Apr 2008 22:22:40 -0700
- 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 UTC