Re: Opera's Proposal for :context Selector

Lachlan Hunt wrote:
> 
> Andrew Fedoniouk wrote:
>> Lachlan Hunt wrote:
>>> Therefore, reusing :root for this would require redefining it for a 
>>> purpose it was not originally intended for.
>>
>> You do not need to redefine it in the first place (in master CSS spec.)
>>
>> It is just enough to put remark in your document - "for in depth 
>> subtree queries :root is the element itself" or something like that.
>> It does not contradict original meaning in HTML/CSS
> 
> No, because that would change the way selectors are evaluated against 
> elements, and which ancestor elements are looked at.
> 
> i.e. Consider the following fragment:
> 
> <body>
>   <section id="foo">
>     <div>
>       ...
>     </div>
>   </section>
> </body>
> 
> foo.querySelector("body div");
> 
> As currently defined and as it is being implemented by browsers, that 
> would match and return the above div element.  This is because the 
> Selectors spec defines whether or not a given element matches a 
> particular element, and the API does not redefine that.

If there are such implementations that have
querySelector(); implemented for arbitrary DOM elements then
without :context/:root they are barely useful.

> 
> If :root were redefined as you suggest, then so would this would need to 
> as well:
> 
> foo.querySelector("body :root div");

No. That is invalid selector. :root can only be defined for the very 
first element of the selector. Otherwise it makes no sense - will always 
be false.

> 
> (Note that will in fact work with the :context selector in place of :root.)

foo.querySelector("body :context div");

That is very ineffective selector.

Say you have N children of the element. Then for all N children
you will execute the same testing sequence "body :context".

In fact such things should be just disallowed.

If you really need such a selector then you should write it as:

var div = self.selectParent("body")? self.selectChild("div"):null;

this will be the most effective way of doing
   foo.querySelector("body :context div");

> 
> But that is also another reason why :root needs to continue matching the 
> document's root element, rather than the contextual root.  Note that the 
> same issue also occurs with scoped stylesheets in HTML5.

So scoped style sheets will have the same problem.
All elements inside will be scanned at least twice for the full depth of 
the tree. That is highly non-desirable. Especially for static systems of
declarations.

I've already implemented style-set's [1] that are such scoped style 
sheets (but defined purely in CSS). We have more than a year of real 
experience of using scoped style systems. I never heard anyone 
expressing the need of matching document root inside scoped style set.

Scoped style sets that use only relative depth for matching elements are 
as much effective as it's possible.


> 
>>> http://dev.w3.org/2006/webapi/selectors-api/
>>
>> 1) I cannot understand phrase "query selector" to be honest. Query it 
>> for what?
> 
> We had a lengthy naming debate about the issue in the WebAPI WG a while 
> back.  After an official working group vote to resolve the issue, that 
> was the winning alternative.  Admittedly, it's not perfect, but the 
> issue is no longer up for discussion.
> 
>> 2) selectors-api appears as impractical for the following reasons:
>>    a) There is a need for parent lookups too,  like:
>>        element.selectParent("ul.foo") - returns nearest matching 
>> parent element.
>>        element.selectLastParent("ul.foo") - returns farthermost 
>> matching parent element.
> 
> The existing API was designed to address many use cases that were 
> significantly from what you are trying to address.  This includes 
> addressing the needs of authors based on existing practices in real 
> world scenarios; in particular, the use of JS libraries that offer 
> similar features.  I'm not aware of, for instance, a JS library that 
> offers any feature remotely like what you're proposing, and the use 
> cases you are trying to address are unclear.

Consider markup like this:

<ul .collapsible>
   ....
   <span .collapser >Click to collapse the list</span>
   ....
</ul>

and code:
collapser.selectParent("ul").setAttribute("collapse","1");

By using static CSS selectors it is simply not possible to find
nearest parent of the type.

"...JS libraries that offer similar features..."

I am not sure what libraries you are talking about but, say,
jQuery allows you to write:

$(this).parent("ul.collapsible")

See: http://docs.jquery.com/Traversing/parent#expr

Moreover: minimal set of selector operations that is needed
for good native support of jQuery contains these three functions:

element.selectChild(selector[, callback]);
element.selectParent(selector[, callback]);
element.matches(selector);


> 
>>    b) querySelectorAll is quite ineffective in practice - it should be 
>> form with callback function. Otherwise it is not clear of what to do with
>>        the returned list in GC environments and functional languages 
>> like JS.
> 
> That makes no sense at all, and it is not an issue that has been raised 
> by either of the 4 major browser vendors who are currently working on 
> implementing the API.
> 

Too bad. That is one of reasons why JS based solutions are slow. Slow by 
design.

Write function that contains something like this
   elem.querySelector("*").length
and you can name it as JoyOfGarbageCollector().

-- 
Andrew Fedoniouk.

http://terrainformatica.com

[1] http://lists.w3.org/Archives/Public/www-style/2008Jul/0034.html

Received on Friday, 11 July 2008 03:41:13 UTC