W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: Clarification on "live NodeList"

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 07 Jul 2009 22:44:00 -0700
Cc: Jeff Schiller <codedread@gmail.com>, HTML WG <public-html@w3.org>
Message-id: <13DECC67-54F9-4A21-9278-97D2AFEAFD51@apple.com>
To: Andrew Fedoniouk <news@terrainformatica.com>

On Jul 7, 2009, at 10:02 PM, Andrew Fedoniouk wrote:

>
> Slightly out of topic, sorry in advance but...
>
> Liveness of such things is the worst imaginable case. Contradicts all
> design principles in GC-able environments like JS. Sigh.
>
> Call 10 times getElementsByName() and you will have 10 dangling lists
> that need to be handled on pretty much each DOM structure update  
> (until
> GC will occur).
>
> Of course caching and lazy evaluation tricks can be used for
> native implementation of document|element.getElementsByClassName() &  
> Co.
> but still substantial amount of code should be executed behind.
>
> It is a pity that such non-effective-known-upfront solutions were
> put at the foundation of HTML5. We can JIT JavaScript itself up to the
> speed of light but such "combinatorial mines" may ruin that crystal
> castle at any point.
>
> And yet... Seems like no one need those NodeLists to be alive.
> I've never seen requests or even intimations on such requests to
> see them alive. Thus is the question: why? for what purpose?

I agree with you that the concept of live NodeLists is not great.  
However, in the case of getElementsByName, this is required by the DOM  
spec and by backwards compatibility. For getElementsByClassName, it  
makes sense to align with ...ByName, ...ByTagName and ...ByTagNameNS  
as specified by DOM Core.

However, because of the complexity with dynamic NodeLists, the new  
Selectors API (querySelectorAll) uses static NodeLists instead. It can  
replace the functionality of all the getElement[s]By... series of  
functions and more. <http://www.w3.org/TR/selectors-api/>

Regards,
Maciej
Received on Wednesday, 8 July 2009 05:44:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:47 UTC