On Jul 28, 2013, at 10:29 AM, James Greene <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > Realized this should probably be a new thread... > > > On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai <[email protected]> wrote: > >> On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking <[email protected]> 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
