[whatwg] iterators intead of live NodeLists WAS: Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Tab Atkins Jr.]

I strongly agree with the use-case, and think some feature for this
would be very helpful.

[Mixing up your emails for reply convenience.]
On Sat, Jul 27, 2013 at 11:25 AM, Ojan Vafai <ojan at chromium.org> wrote:
> On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai <ojan at chromium.org> wrote:
>> var iterator = document.querySelectorAll('div').iterator(); <--- does some
>> magic to not precompute the whole list

Can you describe this magic?  It would be nice if this were somehow
possible, but I'm not sure how it would be.

> There are many places where we expose Sequence<Node> or NodeList that can't
> easily be replaced with hand-rolled DOM walking (e.g. getNamedFlows).
>
> You could imagine NodeIterator taking a Sequence<Node>/NodeList as an
> argument to it's constructor instead of adding an iterator method, but I
> find the NodeIterator interface to be clunky and awkward.

Yeah, having the ability to produce these iterators for any of the
currently-static Node lists would be great.  But again, not sure how
the magic would work. :/

>> while (let current = iterator.next()) { ... }
>>
>> And next always does the walk from the current node. So, if you add a div
>> before the current node, this specific iterator won't hit it, but if you
>> add a div after it would. I'm not sure what should happen though if you
>> remove the node that's the current node. I think I'm OK with the iterator
>> just returning null for the next() call in that case.
>>
>
> Thinking more on this, I think we could make next() still work in the case
> where you remove the node by pointing current at the previous node in the
> tree. Then you could do things like:
>
> while (let current = iterator.next()) { current.remove(); }

This should be an ES iterator, rather than a custom DOM thing that
looks almost exactly like an ES iterator.

> I think the methods we'd want here are next, previous, first and last. That
> way you can walk the iterator forward or backward. This doesn't overlap
> well with NodeIterator's current API.

How useful is it to be able to walk an iterator in both directions at
the same time?  I suppose we can produce an iterator subclass that
also has the additional methods we want.

~TJ