- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Fri, 18 Jul 2008 09:35:04 +0200
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: public-webapps <public-webapps@w3.org>
-www-style +public-webapps Andrew Fedoniouk wrote: > Lachlan Hunt wrote: >> 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. > > I am not sure I understand problems you have mentioned. > > Mathematically any sub-tree is a tree by itself in DOM alike graphs. > Root element is not anyhow different from any other elements in the DOM > if to speak about CSS selectors. What you need is described as solution 5 in this email I showed you before. http://lists.w3.org/Archives/Public/public-webapi/2008May/0057.html > My proposal to treat :scope as such a :root > > :root>ul>li {} > > does not require to change anything. At all. But what you're asking for still suffers from the problems of solutions 3 and 4 because :root is defined to match the root element of the document. > Your idea requires special :scope pseudo that has to be dealt separately > in querySelector and in CSS selectors - so to *change* the way how > selectors are handled now. Solution 5 requires changing the way selectors are parsed in order to allow combinators to appear at the beginning. I am working on finding a solution to that problem. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0181.html I'm also trying to find a way to allow it to match sibling elements and their descendants as well, like JQuery does for, e.g. foo.find("+p") >> 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. > > I've seen people use jQuery but have not seen people using or requesting > such "additional filtering", terribly sorry. That is why I asked. > As I said before full depth lookups are ineffective for scoped cases. > Technically it would be just a bug of specification if you would ask > any mathematician. The problem is if I were to change querySelector is defined now, we already have implementations that are getting close to shipping and such a huge change could majorly delay things. Plus, we haven't entirely solved the technical issues. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Friday, 18 July 2008 07:35:49 UTC