- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Tue, 13 Aug 2013 14:03:59 -0700
- To: Ojan Vafai <ojan@chromium.org>, James Greene <james.m.greene@gmail.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Jonas Sicking <jonas@sicking.cc>
On Jul 28, 2013, at 10:29 AM, James Greene <james.m.greene@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@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@chromium.org> wrote:
> Realized this should probably be a new thread...
>
>
> On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai <ojan@chromium.org> wrote:
>
>> On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking <jonas@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
Received on Tuesday, 13 August 2013 21:04:24 UTC