Re: Opera's Proposal for :context Selector

Bjoern Hoehrmann wrote:
> * Lachlan Hunt wrote:
>>   This is a proposal for a new :context pseudo-class designed to match 
>> the context node of a query, where the the scope of elements that match 
>> a given Selector is constrained to be within a subtree rooted by a 
>> particular node.
> 
> If we do this, we should say that selectors are evaluated in a context,
> and that the context optionally consists of (among things like default
> namespace and namespace bindings) an element called the context element
> and the context element and only the context element matches :context.

Yes, that is basically how it works.  Note that :context does not 
necessary match the context node, as defined in the proposal.  Rather, 
it matches a specific element node that is determined based upon what 
the context node is. The only exception is for the special handling of 
DocumentFragments, see below.

e.g. Assuming the document is HTML:

document.querySelector(":context>body");

In this case, the context node is the document, but :context matches the 
html element.

In the case of elements:

<div id="foo">
   <p>...
</div>

var foo = document.getElementById("foo");
foo.querySelector(":context>p");

The :context pseudo-class would match the div element

> By definition, pseudo-classes constrain which elements selectors match,
> and :context would always be equivalent to *:context (modulo namespaces)
> so it cannot match other node types like inexistant element nodes or a
> document node,

It never matches match a Document node, it would match the root element 
of the document instead.

But in the case of DocumentFragment, I wanted to provide a way to match 
only child elements of that fragment, and pretending it was an element 
was the only workable solution I could find.

e.g.
#DocumentFragment
+-<span> (A)
| |
| +-<span>
|
+-<em>
|
+-<span> (B)
   |
   +-<span>

fragment.querySelector(":context>span");

This should only match the two top level span elements, marked (A) and 
(B) above.  Without it, all four span elements would be matched with no 
way to filter out the two undesired ones.

I considered defining a new pseudo-element to handle that case instead, 
but it just added made the spec far too complex and would have made life 
more difficult for authors.

> If other node types are crucial to the proposal, I think you'll have to 
> use a different construct than a pseudo-class.

The methods in Selectors API are defined to apply to Document, 
DocumentFragment and Element nodes.  So, defining behaviour for at least 
those cases is essential.  Defining behaviour in the case of all other 
nodes is just making sure there's no holes left behind.

But whether or not it is essential to make :context match 
DocumentFragments will depend on feedback from JavaScript developers and 
whether the use cases for it are really justified.

> I am also not sure why you have a definition of "scope" in the proposal, 
> and I don't understand its definition (it is procedural, that might be 
> the problem). Could you  say why a definition of "scope" is needed, as
> opposed to using my definition above?

With the way I was defining the behaviour, I needed a way to refer to 
the set of elements which could be matched by the the given selector. 
Rephrasing it in another way, perhaps based on your above suggestion 
could also work.

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

Received on Thursday, 10 July 2008 22:56:53 UTC