- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 28 Jul 2013 18:37:07 -0700
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>, DOM WG <www-dom@w3.org>
On Sun, Jul 28, 2013 at 11:02 AM, François REMY <francois.remy.dev@outlook.com> wrote: > 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) Yes. > - 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) 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 node, going either forwards or backwards in the DOM. Then give it an @@iterator attribute holding the nodes() method. (This just means that, if used nakedly in in for-of loop, without explicity calling one of the iterator-returning methods, it'll use the nodes() iterator.) (Names of the iterator methods up for discussion, obviously.) ~TJ
Received on Monday, 29 July 2013 01:38:02 UTC