Thoughts on querySelectorAll

  <div><p id="foo"><span></span></p></div>
  <script src="http://o.aolcdn.com/dojo/1.1.0/dojo/dojo.xd.js"></script>
  <script>
  var foo = document.getElementById("foo");
  // should return nothing
  alert( dojo.query('div span', foo).length );
  // will return the SPAN (booo!)
  alert( foo.querySelectorAll('div span').length );
  </script>

  // jQuery
  $("#foo").find("> span");
  
  // DOM
  document.getElementById("foo").querySelectorAll(":root > span")

  try {
    document.querySelectorAll("div:foo");
  } catch(e) {
    alert(e); // "Error: SYNTAX_ERR: DOM Exception 12"
  }

  var selector = "div:foo";
  try {
    document.querySelectorAll(selector);
  } catch(e) {
    alert(selector.slice(e.position)); // ":foo"
  }

  try {
    results = document.querySelectorAll(selector);
  } catch(e) {
    results = filterQuery(
      document.querySelectorAll( selector.slice(0, e.position) ),
      selector.slice(e.position)
    );
  }

Posted: April 30th, 2008

15 Comments (Show Comments)

1. Paul Bakaus (April 30, 2008 at 4:17 pm)

   Makes perfect sense to me.

2. Borgar (April 30, 2008 at 5:10 pm)

   A while back I wrote a selector engine.

   During testing and adding querySelectorAll support I filed a bug against this behavior with WebKit. For the obvious reason that it was doing something unexpected.

   I had to read the spec a few more times until it finally sunk through. Why why why would they do this? (I would still like to know why and how this conclusion was reached).

   I foresee that this will cause a great many more bug reports.

   Also ironically, since we’re basically stuck with mutating the selector (I use selector.replace(/(^|,)\s*/g,'$1#'+context.id+' ');) error reporting back to user becomes slightly presumptuous.

   Buy hey, on the bright side, MSIE followed to the spec on this one.

3. John Resig (April 30, 2008 at 5:48 pm)

   Note: There’s an active discussion occurring over on the webapi mailing list concerning my suggestions:
   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/thread.html#msg251

4. Sean Hogan (April 30, 2008 at 8:22 pm)

   I suspect that finding querySelectorAll intuitive or not depends on how you read css selectors.

   If “div span” is read as “find div elements and for each of those find descendant span elements (exclude duplicates)” then you might expect foo.querySelectorAll(“div span”) to find div descendants of #foo and then span descendants of the divs.

   If “div span” is read as “find span elements that are descendants of div elements” then you might expect foo.querySelectorAll(“div span”) to find descendants of #foo that are span elements and descendants of div elements.

   The second way matches the way the w3 selectors spec is written.

   None of this is to say the current way is right (or even preferable).

5. voracity (April 30, 2008 at 9:45 pm)

   HTML et al. seem to have major problems with modularity — and it harms our code’s simplicity, security and independence.

   The global scope is not special — it’s just another node in the hierarchy. Same with the document scope.

6. Jake Archibald (May 1, 2008 at 8:37 am)

   I believe that Firefox processes selectors in reverse when it applies CSS rules. I could be completely wrong, but if this is the trend of the browser manufacturers it might explain why the spec went that way.

   Have there been any experiments writing a selector query in JS this way? Could it be faster?

7. Borgar (May 1, 2008 at 3:54 pm)

   @Jake Archibald:

   I’m pretty sure NWMatcher processes selectors left-to-right, though I could be wrong. It is very fast on most browsers.

8. Johan Sundström (May 1, 2008 at 3:55 pm)

   From my perspective, the W3C-suggested behaviour is useful too, though quite likely for a much less frequent use case – finding all nodes below your context node, that gets CSS rules from the given selector applied.

   Don’t knock that use case as completely useless just because it is not the problem you to use querySelectorAll for. You are most likely quite correct it is of much more marginal interest, relative to the use case of finding nodes where all parts of the selector are found below the context node, however, and that the API consumer should rather have to walk that extra mile for the uncommon use case, instead of making it the default behaviour.

9. Rob (May 2, 2008 at 7:37 am)

   I may well be missing something here but why not just use xpath?

10. John Resig (May 2, 2008 at 1:07 pm)

    @Rob: querySelectorAll is orders-of-magnitude faster than XPath.

11. Tom (May 2, 2008 at 1:07 pm)

    Rob, in IE (6, at least), XPath doesn’t work for plain HTML. Also, it’s nice to use the same query language from scripts as for CSS.

12. Mariusz Nowak (May 2, 2008 at 3:05 pm)

    @Rob
    It think it went that way because developers are much more familiar with Selectors (cause of CSS) and it’s not that easy to dive into XPath for novice.
    But indeed XPath is much more powerful and I miss ability to query in any direction with Selectors – it’s a big drawback.
    Concerning speed difference between both I’m not sure whether it really counts at that level of implementation (?)

    @John
    When I read above article at first I agreed with every word but after I read mailing list I’m not sure. After all the way they made it makes sense, just adding ‘:scope’ (not using ‘:root’) would help.
    Due to limitation of Selectors there always will be some limits, like – get first previous div sibling – sounds simple but we can’t do that with Selectors.
    By the way – how do you deal with such limits in your work? Have you thought of some ‘reverse Selectors’ engine for use in JavaScript? or you just iterate DOM tree for such cases.

13. Tino Zijdel (May 3, 2008 at 8:05 pm)

    John, wasn’t it you that criticized other libraries on paying to much attention on performance of very uncommon uses of query-selectors? Are you now seeking for means to rebute them through this new API?

    Although selector-performance may be an issue in some cases I’d say that focussing on something that is usually not an issue at all in common pages, or focussing on core JS performance in general when it’s not an issue compared to the real performance bottle-neck (being rendering of DOM-changes) is just not very usefull.

    I’m working on some benchmarks that test actual browser dynamic-render-performance; if you have some ideas to share I’m all ears.

14. Rasmus (May 6, 2008 at 8:17 am)

    The naming seems a bit Monty Pythonesque:

    “And now for somwthing completely different…”

    Given getElementsByTagName and getElementById you’d think something like getElements and getElement would be next.

    “querySelectorAll” doesn’t even make sense; 3 words thrown together! When I first came across getElementsByTagName I thought “what a long-winded method name” – but I immediately understood what it was for!

    Naming a method should optimally result in a short descriptive name (in a perfect world). There are lots of examples of short abstractly named methods out there and examples of long paint-me-a-picture named methods. But why would you choose the worst of both worlds – short and abstract?

    It’s like getting a porsche – but pink and brown striped… but it’s a porsche though.;)

15. Asbjørn Ulsberg (May 8, 2008 at 8:19 am)

    Rasmus, I completely agree. querySelectorAll is a horrible name. But it was discussed for a long while and finally an internal W3C-member only vote was cast which declared querySelectorAll as the winner. I don’t think it won by large margin, but it was more like the option that got less negative votes.

    I also agree with your comments, John. The only way I think querySelectorAll to make sense when rooted at an Element, is how it’s implemented in jQuery. The algorithm proposed by W3C isn’t consistent with anything deployed in the wild and not even with W3C’s own CSS selector proposals. Thus, foo.querySelectorAll('span a') should only return a elements that are descendants of span elements that are descendants of the element foo.

    How this is implemented in browsers is pretty uninteresting and whether this is less optimal than the existing CSS algorithms (that I presume are all rooted in the document object before evaluation) is of less importance than whether it will be faster than a JavaScript-only solution. As long as it’s faster than what we have, who cares whether it’s 53ms slower than the optimal implementation or not?

Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.