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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 2 Apr 2008 10:43:20 -0700
Cc: Henri Sivonen <hsivonen@iki.fi>, Boris Zbarsky <bzbarsky@mit.edu>, "Web APIs WG (public)" <public-webapi@w3.org>
Message-Id: <0FD3CA92-7D92-4FEB-A0A0-13A3F6F580F3@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

On Apr 2, 2008, at 2:44 AM, Jonas Sicking wrote:

> Henri Sivonen wrote:
>> On Apr 2, 2008, at 00:48, Boris Zbarsky wrote:
>>> OK.  So item() would be available on Element after casting it to  
>>> NodeList in those implementations.  I guess you're saying that the  
>>> cast would not longer be unambiguous if there were multiple  
>>> NodeLists that might make sense?  So childElements couldn't be  
>>> implemented with a |return this;|?
>>> That doesn't seem like such a terrible implementation burden to  
>>> me, to be honest...
>> I'm not claiming it would be awfully hard, but it does change the  
>> impact of Element Traversal from adding four or five methods on an  
>> existing class (mere code footprint; super-simple) to adding more  
>> run-time object instances. And then, there are issues like should  
>> childElements return the same object every time. And if yes, then  
>> the implementor needs to add a new pointer to each element node or  
>> to add a hashtable on the owner document or something along those  
>> lines. Again, not awfully hard, but still more complex than just  
>> adding convenience methods on an existing class.
> Sure it's more complex, but it's still trivial.

In WebKit, it would be more than one line of code to add a new kind of  
NodeList. Not a ridiculous amount of code though.

However, I think live NodeLists are an anti-pattern. They tend to be  
horrible for performance in the face of mutation (and even when there  
isn't mutation, extra objects are allocated). This is part of why I  
strongly argued for querySelectorAll to return a non-live list. And  
using indexing is not really any more convenient than using next/ 
previous methods.

I can live with the editor's decision either way on this one.

Received on Wednesday, 2 April 2008 17:43:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC