This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See <http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0033.html>.
It would be nice to have some kind of data how often TreeWalker code is invoked in browsers on average. (And maybe make sure to not count Acid3 runs.) We can make logical additions, but if nobody uses it there is no point.
+1 for me. More than once I've written a RejectChildrenFilter specifically to allow for a node to be accepted but for its children to be rejected. It's historically been the first thing I think about when it comes to TreeWalker.
Note that this would be a pretty different implementation-wise (and to some extent behavior-wise) from he current filters. The current filters are implemented by calling the filter function for each node as we scan the tree trying to figure out which node to return. Once we have found a node we set the currentNode and return it. No state is used during the scanning and no state is retained from the scanning. Next time we need to scan for a new node to walk to, the only input into that algorithm is the currentNode that is used as a starting point for the scanning. In order to implement this new proposed value we would need to either remember the fact that the current node returned FILTER_NO_CHILDREN. Or we would need to re-test the currentNode when we start a new scan. Put it another way. How would you expect the following to behave: DOM: <html> <body> <div> text here </div> </body> </html> JS: walker = document.createTreeWalker(document.documentElement, SHOW_ELEMENT, function(node) { if (node.dataset.hideChildren) return FILTER_NO_CHILDREN; return FILTER_ACCEPT; }); walker.firstChild(); assert(walker.currentNode == document.body); // true document.body.dataset.hideChildren = "true"; walker.nextNode(); What is walker.currentNode at this point?
(In reply to comment #1) > It would be nice to have some kind of data how often TreeWalker code is > invoked in browsers on average. (And maybe make sure to not count Acid3 > runs.) We can make logical additions, but if nobody uses it there is no > point. Actually this proposal is brought by two posts on my blog that talk of an interview quiz for front-end web developers: how to filter DOM nodes on given condition (written in Chinese, don't know whether you could read). http://forcefront.com/2012/an-interview-quiz-filtered-dom-selector/ http://forcefront.com/2012/an-interview-quiz-filtered-dom-selector-continued/ As professional developers, we are encouraged to find various solutions so as to choose the best one and make websites better. Well yes, I don't see anyone using TreeWalker or NodeIterator. Why? Because they suck! TreeWalker is the slowest one among five solutions I provided. The best one is ten time faster than it! And by the way, I don't think whether to fix a bug in spec depends on the number of people facing it. That's browser vendors' job. Since W3C focuses on delivering standards, the primary consideration should be "whether it is a bug or not". "Oh, since nobody's using, so be it." There's an old saying in China: smash a pot to pieces just because it's cracked, which means to write oneself off as hopeless and act recklessly.
> In order to implement this new proposed value we would need to either remember > the fact that the current node returned FILTER_NO_CHILDREN. Right. That doesn't seem too terrible to me, for what it's worth....
It would result in somewhat awkward behavior in the example in comment 3, but I agree it's probably the best solution.
If someone implements this we'll add it to the standard.
Given the lack of interest in two years closing this as WONTFIX. Please let me know if you find two browsers willing to implement this. (Probably best reported as a new issue on GitHub.)