Re: Opera's Proposal for :context Selector

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 :root were redefined as you suggest, then so would this would need to 
as well:

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

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

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.

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

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

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Friday, 11 July 2008 00:31:44 UTC