W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

RE: [DOM4] Short and Efficent DOM Traversal

From: Francois REMY <francois.remy.dev@outlook.com>
Date: Sun, 28 Jul 2013 19:28:00 -0700
Message-ID: <DUB404-EAS2007B3EA419FB0D5AF85D8FA5550@phx.gbl>
To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>
CC: "'Jonas Sicking'" <jonas@sicking.cc>, <public-webapps@w3.org>, "'DOM WG'" <www-dom@w3.org>
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 ;-)
Received on Monday, 29 July 2013 02:28:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:12 UTC