- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 27 Jul 2013 20:38:28 -0700
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, DOM WG <www-dom@w3.org>
- Message-ID: <CA+c2ei-YW3ngHFGUXRrZQHpKQprx23AbSRtH+P0eaLXRYkD8Zg@mail.gmail.com>
On Jul 27, 2013 6:55 PM, "François REMY" <francois.remy.dev@outlook.com> wrote: > > TL/DR: CSS Selectors represent the most commonly used way to perform search in the DOM. But, until now, you’ve to choose between using CSS (querySelectorAll) or doing incremental search (createTreeWalker). I think we should try to fix that. > > The proposal here would be to accept CSS selectors in replacement to the existing whatToShow flags {which are difficult to use and not entirely satisfying}, i.e. overloading the createTreeWalker/createNodeIterator functions to take a CSS Selector in the form of a string as a second parameter. > >> >> var tw = document.createTreeWalker(document.body, “ul.menu > li”); >> while(tw.nextNode()) { >> if(...) break; >> ... >> } > > > Advantages: > > It’s much faster than to use a javascript function as a filter that would call again the browser stack to find out whether a CSS selector match or not a specific element > > We do not loose the ability to provide a more complex piece of javascript if we really need it, but we reduced the cases where we need one. > > It’s less code to write (CSS is more efficient than any piece of JS) > > It allows getting rid of the long named constants nobody likes to use > > In addition, it would open huge optimization opportunities for the browser (like skipping siblings that look similar, not entering into descendants if it’s known a certain css class is not present among them, reusing cached lists of elements matching a selector, or whatever). > > Thougths? Unfortunately the treewalker and nodeiterator both carry weird baggage. They are both very java-esq in design. The TreeWalker can walk in a treelike manner or iterate as a list, and follows nodes if they are moved out of the Document. The NodeIterator can just iterate as a list but has an anchoring feature that keeps it in the main Document tree at all times. Why are those two features linked? Also, modifying the existing TreeWalker/NodeIterator will make feature detection harder. 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. / Jonas
Received on Sunday, 28 July 2013 03:38:56 UTC