W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: Opera's Proposal for :context Selector

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Thu, 17 Jul 2008 19:50:29 -0700
Message-ID: <488004F5.7070301@terrainformatica.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
CC: www-style <www-style@w3.org>

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.

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT