Re: Opera's Proposal for :context Selector

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.

My proposal to treat :scope as such a :root

   :root>ul>li {}

does not require to change anything. At all.

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.

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

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.

> 
> 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");

Write it as:

   elements = foo.querySelectorAll(".a:root section, .b:root article");

and result will be the same if querySelector will use local lookups.

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

That is what I am trying to understand: why to have strictly
speaking buggy version at the very first place?

Sorry but idea, motivation and purpose of all this are quite fuzzy.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 18 July 2008 02:51:02 UTC