W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2013

RE: [DOM4] Short and Efficent DOM Traversal

From: François REMY <francois.remy.dev@outlook.com>
Date: Sun, 28 Jul 2013 06:49:02 +0200
Message-ID: <DUB120-W144DA8532357D95DF371C5A5540@phx.gbl>
To: Jonas Sicking <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, DOM WG <www-dom@w3.org>
> I like the idea of being able to get lazy iterators and treewalkers. 
> And that are driven by selectors. But I think creating a new feature 
> rather than trying to retrofit existing ones will be more successful. 

Why? I need *exactly* the behavior the TreeWalker is offering me now: ie a lazy way to walk the DOM from any starting point. The only stupid thing is that I'm forced to reduce my performance by doing this:

  var tw = document.createTreeWalker(region, ELEMENTS, function(e) { return e.matchesSelector("xxxx") }, ...);
  tw.currentNode = myStartNode; if(tw.nextNode()) return tw.currentNode;  

which is suboptimal because the execution context switch back and forth between JS and the native engine all the time, and the native engine do not make use of the selector to prune the tree walking where it could.

Really, what I need is just plain that:

  var tw = document.createTreeWalker(region, "xxxxx");
  tw.currentNode = myStartNode; if(tw.nextNode()) return tw.currentNode;

Feature detection, by the way, is not very hard. Try to create any treewalker with a string parameter and, if it fails, then polyfill by using previously shown method.

I don't get why everybody want to create something new that is a simple iterator and doesn't solve my use case while the current design solve my use case and just need to be improved dramatically from both the usability and performance point of view by adding the power of CSS selectors to it...

Is there any reason everybody hate TreeWalker? 		 	   		  
Received on Sunday, 28 July 2013 04:49:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:03 UTC