[whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Ryosuke Niwa]

On Jul 28, 2013, at 4:24 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Sun, Jul 28, 2013 at 1:59 PM, Ojan Vafai <ojan at chromium.org> wrote:
>> 
>> I was just picturing lazy computing the list. You don't need to compute the
>> list until you query the length or index into the NodeList, at which point,
>> if it's a static NodeList, you compute the whole thing in one go. If all you
>> ever do is grab the iterator, then no need to compute the list. So, the
>> example you give above would not precompute.

How common is it for an author to call querySelectorAll and then NOT iterate over it?
If the author simply wanted the first element, then the author should be calling querySelector instead.

>> Now that I put it in writing, the obvious problem with this is that it's a
>> change in semantics. If you querySelectorAll and then modify the DOM before
>> reading the length or an index, then you get a different list. :(
> 
> It's not just a change in semantics, it's a change in behavior. To
> keep the same behavior you would have to make the static NodeList
> observe the DOM and precompute itself as soon as the DOM was modified.
> 
> I.e. static NodeLists would incur the same performance problems that
> Ryosuke expressed concern about that live NodeLists have.
> 
> So yeah, I don't think it's an option.
> 
> In general, I'm not a big fan of anything that adds capabilities to
> "all NodeLists". This has been brought up in the past when people
> suggested adding the ability to observe changes to "all NodeLists".
> 
> It's not at all obvious to me that in *all* situations where we use
> NodeLists that it is desired to be able to iterate the results lazily.
> Requiring that might force implementations to spend a lot of time
> implementing something that doesn't have use cases.
> 
> We should think of NodeLists as simple Arrays. And it's clear that we
> don't want to force any function that returns an Array to be able to
> lazily compute that Array using an iterator. Keep in mind that the
> laziness is observable, so it's not a valid implementation strategy to
> only do the lazyness where there are clear performance benefits.

Yeah.  We could copy-on-write; i.e. do not allocate a node list as an array until DOM is about to be modified.
But it's quite tricky to do this correctly.

What are specific use cases under which statically allocating a node list is lower?

- R. Niwa