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

[Ryosuke Niwa]

On Jul 28, 2013, at 10:29 AM, James Greene <james.m.greene at gmail.com> wrote:

> I think it makes sense, too. That said, if the goal is to REPLACE the
> NodeIterator and TreeWalker APIs completely, it wouldn't be all that
> valuable for me as my most common use case has always been to get TEXT
> NODES from under a root node based on some CSS filtering of its ancestor
> nodes.

NodeIterator already has an ability to only include text nodes.

It appears to me that we can also add an ability to match a selector.

e.g.  var nodeIterator = document.createNodeIterator(root, NodeFilter.SHOW_TEXT, null, 'div a');

can find all text nodes under elements that match 'div a'.


On Jul 27, 2013, at 1:04 PM, Ojan Vafai <ojan at chromium.org> wrote:

> 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.
> 
> 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.

NodeIterator has nextNode() and previousNode() already.  Why can't we add firstNode() and lastNode()?


On Jul 27, 2013, at 11:25 AM, Ojan Vafai <ojan at chromium.org> wrote:

> Realized this should probably be a new thread...
> 
> 
> On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai <ojan at chromium.org> wrote:
> 
>> On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> I think these are good points of what is lost by using static NodeLists. I
>> still feel pretty strongly though that these benefits don't outweigh the
>> costs. If we want to give people most of the benefits of live NodeLists
>> without the costs we could expose an iterator API:
>> 
>> var iterator = document.querySelectorAll('div').iterator(); <--- does some
>> magic to not precompute the whole list
>> 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 gets the performance benefits of live NodeLists, I think meets the

What happens when you remove the previous node during the iteration?

- R. Niwa