W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: Opera's Proposal for :context Selector

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Fri, 18 Jul 2008 09:35:04 +0200
Message-ID: <488047A8.3090702@lachy.id.au>
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: public-webapps <public-webapps@w3.org>


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.


> 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.


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
Received on Friday, 18 July 2008 07:35:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC