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

[James Greene]

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. If the proposed API used only CSS query selectors without also
allowing the additional NodeType filtering provided "whatToShow", then it
could not not be used to directly gather text nodes.

Might be OK to leave text nodes out... not sure how others use NIs/TWs.

Sincerely,
   James Greene
On Jul 28, 2013 11:24 AM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:

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