> I hate TreeWalker because it's an iterator but not an ES Iterator.
> DOM is broken, legacy cruft, etc.
As far as I know, an iterator can only go forward, not backward (while a tree
walker can). But I agree 90% of the use cases map to a forward navigation and
it would be nice to support for-of for this use case. We could obviously add a
field to inverse the forward direction so that the roles nextNode and
previousNode are reversed (in such case, you could use for-of in whatever
direction, and even change the direction inside the for-of if needed, which is
really nice).
> I'm fine with something that exposes TreeWalker's abilities to start
> from a given node, but that returns an ES iterator, like Domenic says.
If I'm not mistaken, all it takes for this to work is to add an .iterator()
function on the TreeWalker/NodeIterator interface that would return an object
calling nextNode() on the TreeWalker/NodeIterator and format properly the
return values.
> Given that we can overload the arguments, as you describe, I'm okay
> with reusing the existing method for this.
So, let's sum this up. The proposed changes are:
- a new overload of createTreeWalker/createNodeIterator whose second argument
can be a string representing a CSS selector, with the other arguments now being
optional (not forced to pass null).
- a new 'cssFilter' field on TreeWalker/NodeIterator that would return the
cssFilter used for pre-filter elements (or an empty string if none was given)
- a new 'iterator' function on TreeWalker/NodeIterator that would return an ES
iterator (i.e. make TreeWalker/NodeIterator iterable with for-of support)
- 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)
I would like to hear implementor feedback on this, but I bet the changes are
not very hard to implement and would give a whole new light to the DOM
Traversal types by making them actually efficient and natively usable from the
ES6 world.
Is anyone willing to write the necessary spec changes or should I make a pull
request on the Overview.src.html file to initiate the proposal discussion?
