- 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