18540 2012-08-12 20:15:23 +0000 Proposal for a new acceptNode() return value for TreeWalker. 2016-03-14 13:07:37 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All Windows 3.1 RESOLVED WONTFIX blocked on implementers weighing in P2 normal --- 1 Ms2ger annevk ajvincent bzbarsky jonas kennyluck mike myst.dg www-dom public-webapps-bugzilla oldest_to_newest 72089 0 Ms2ger 2012-08-12 20:15:23 +0000 See <http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0033.html>. 74200 1 annevk 2012-09-21 10:31:17 +0000 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. 77182 2 ajvincent 2012-10-27 08:46:48 +0000 +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. 83441 3 jonas 2013-02-20 23:42:26 +0000 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? 84129 4 myst.dg 2013-03-08 18:45:09 +0000 (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. 84254 5 bzbarsky 2013-03-11 17:04:32 +0000 > 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.... 84287 6 jonas 2013-03-12 05:12:19 +0000 It would result in somewhat awkward behavior in the example in comment 3, but I agree it's probably the best solution. 106645 7 annevk 2014-05-22 13:46:02 +0000 If someone implements this we'll add it to the standard. 125461 8 annevk 2016-03-14 13:07:37 +0000 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.)