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

[Jonas Sicking]

On Sun, Jul 28, 2013 at 1:59 PM, Ojan Vafai <ojan at chromium.org> wrote:
> On Sun, Jul 28, 2013 at 11:10 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>
>> On 7/27/13 10:58 AM, Ojan Vafai wrote:
>>>
>>> var iterator = document.querySelectorAll('div').iterator(); <--- does
>>> some magic to not precompute the whole list
>>
>>
>> Well, so... not precompute but make it some sort of live, or not
>> precompute but represent a frozen set of nodes?
>>
>> What should happen with this situation:
>>
>>   var list = document.querySelectorAll('div');
>>   var iterator = list.iterator();
>>
>> Should the list of nodes be precomputed in this case?
>>
>> Basically, the magic sounds like it's ... very magical.  Magical enough
>> that authors would have a tough time with this setup, even ignoring
>> implementation concerns.
>
>
> 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.
>
> 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.

/ Jonas