Bug 18540 - Proposal for a new acceptNode() return value for TreeWalker.
Proposal for a new acceptNode() return value for TreeWalker.
Status: NEW
Product: WebAppsWG
Classification: Unclassified
Component: DOM
unspecified
All Windows 3.1
: P2 normal
: ---
Assigned To: Anne
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-12 20:15 UTC by Ms2ger
Modified: 2013-03-12 05:12 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Anne 2012-09-21 10:31:17 UTC
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.
Comment 2 Alex Vincent 2012-10-27 08:46:48 UTC
+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.
Comment 3 Jonas Sicking 2013-02-20 23:42:26 UTC
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?
Comment 4 Leo Deng 2013-03-08 18:45:09 UTC
(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.
Comment 5 Boris Zbarsky 2013-03-11 17:04:32 UTC
> 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....
Comment 6 Jonas Sicking 2013-03-12 05:12:19 UTC
It would result in somewhat awkward behavior in the example in comment 3, but I agree it's probably the best solution.