RE: [DOM4] Short and Efficent DOM Traversal

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

Received on Sunday, 28 July 2013 18:03:11 UTC