- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 28 Jul 2013 09:24:16 -0700
- To: Ojan Vafai <ojan@chromium.org>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Jonas Sicking <jonas@sicking.cc>
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@chromium.org> wrote: > On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai <ojan@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
Received on Sunday, 28 July 2013 16:25:00 UTC