- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Fri, 18 Jul 2008 01:15:55 +0200
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: www-style <www-style@w3.org>
Andrew Fedoniouk wrote: >> Bert Bos wrote: >>> (It seems to me you shouldn't need it at all. The problem seems to be >>> that x.querySelector(":root") doesn't return x. That looks strange to >>> me: you pass a tree and a pattern, and you get something outside the >>> tree!? But I'm not an expert on that spec...) >> >> The API doesn't change the way in which an element is evaluated >> against a selector; it's still evaluated in the context of the entire >> document. All it does is limit the collection of elements that are >> evaluated against it. >> > do you have any particular use cases for such a behavior? At > last: who requested such querySelector(), where that demand came from? It was done this way for mostly for technical reasons, many of which are explained in the the following email. Basically, it was mostly to avoid changing the way selectors work, or how they are parsed. http://lists.w3.org/Archives/Public/public-webapi/2008May/0057.html It also addresses the majority of use cases while remaining quite flexible, especially when combined with :scope. It allows, for example, to do additional filtering based on the state of scope element itself, or its ancestors. e.g. Consider wanting to select and modify a different set of elements based on the scope element's class name. You could do that like this: if (foo.className == "a") { elements = foo.querySelectorAll("section"); } else if (foo.className == "b") { elements = foo.querySelectorAll("article"); } That could instead be written as elements = foo.querySelectorAll(".a:scope section, .b:scope article"); But keep in mind that I already told you that we're looking into providing an alternative solution (probably queryScopedSelector or something) is version 2 that does what you're asking for using an implied :scope. There are still technical issues to work out before this will be done though, as it will require changing the way selectors are parsed in order to handle combinators at the beginning. e.g. ">em,>strong" or "+p", as well as allowing it to match the element's siblings, rather than just descendants. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Thursday, 17 July 2008 23:16:36 UTC