On Sun, Jul 28, 2013 at 7:28 PM, Francois REMY <[email protected]> wrote: > Cool to see my CSS Filter thing seems the less controversial part of the mix > :-) > >> > - a new 'iterateBackwards' boolean field on TreeWalker/NodeIterator >> > that would make any ES iterator call previousNode() instead of >> > nextNode() when computing the next iteration (to make navigation >> > possible in both direction using ES iterators) >> >> Not quite. Let a TreeWalker be an iterable (an object >> capable of producing an iterator). Give it two methods, >> nodes() and previousNodes(). Each return an ES iterator, >> starting from the TreeWalker's current nod, going either >> forwards or backwards in the DOM. Then give it an >> @@iterator attribute holding the nodes() method. > > I agree it provides a much better semantic and allow to create as many > indepemdant iterators as needed but it also means I can't change the > direction of progress during the iteration. Granted, if I want to do that, > maybe for-of isn't the best option anyway and I can still use .nextNode() / > .previousNode() manually like I do now. So, let it be that way.
Yeah, you can always just iterate manually if you want to skip back and forth, so I don't think this is a big deal. > For symmetry with the existing methods, I would call the two > iterator-generating functions .nextNodes() and .previousNodes() whose > .nextNodes() would have the newly defined [Iterator] attribute, but that's > just my 2 cents ;-) Sure. ~TJ
