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. 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 ;-)
