I think we're getting caught up in the fact that it looks like a simple
selector. As mentioned elsewhere - it could be a completely different syntax,
or keyword, and it would still be an acceptable solution (I was just using it
as an example since it was already proposed).
Of course, there is another option: Allow for leading combinators and fix
Element.querySelectorAll to work within the right context. Neither one of those
would require new syntax to be introduced - simply the addition of (I would
assume) some new parsing rules to handle the leading combinator.
I also wanted to point out that :scope, as I proposed, would NOT be equivalent
to descendant-or-self ONLY equal to 'self'. It would have no other definition
but to represent the base element from which the query is being done.
Jonas, you mentioned p:scope. If that was added then obviously that would add a
lot of work and extra overhead. *However* it would be immensely useful to
developers as it would give them the ability to do a filter operation on the
current node, for example:
// Does the current node match p.class[foo]
Element.querySelectorAll("p.class[foo]:scope")
We should probably have a separate discussion about that, remove it from the
current context of what we're analyzing here.
--John
----- Original Message -----
From: "Jonas Sicking" <[EMAIL PROTECTED]>
To: "Bjoern Hoehrmann" <[EMAIL PROTECTED]>
Cc: "John Resig" <[EMAIL PROTECTED]>, "L. David Baron" <[EMAIL PROTECTED]>,
[email protected]
Sent: Wednesday, April 30, 2008 8:57:32 PM GMT -05:00 US/Canada Eastern
Subject: Re: [SelectorsAPI] Thoughts on querySelectorAll
Bjoern Hoehrmann wrote:
> * Jonas Sicking wrote:
>> It's not so much fact that it's a pseudo-class, but rather that it's a
>> "simple selector" (sorry dbaron, don't know the correct term) which
>> $self would be too. Unless we're redefining the CSS parsing rules which
>> would mean that we have a lot of work remaining.
>
> The problem with using a pseudo-class, and I understood you to say as
> much, is that right now e.querySelector(":a > b") would match any 'b'
> element that has a parent element that both matches the 'a' condition
> and is a descendant of 'e'. Except with :scope, where "descendant" be-
> comes "descendant-or-self". So it would be magic among the pseudo-
> classes. If some other syntax is used, there would not be a magic
> pseudo-class, which raises less of the questions you were asking. I'm
> not sure why this would not address the problem, clearly you would've
> to specify how to parse and interpret the new syntax, right now $self
> (or whatever syntax you'd use) is not valid in selectors.
The DOM walking isn't done in the matching for the pseudo selector, but
rater in the code for the '>' combinator. So it's the code for the '>'
that will prevent matching on the 'self', not the code for the
pseudo-selector.
Note that current implementations of Selectors not by starting at the
first selector, ":a", finding all nodes that match that, then find all
descendants named "b" of those nodes.
Instead, they work by given a node and a selector, testing if the given
node matches the selector. This is the solution you need when doing CSS
styling, test single node against a set of selectors.
At least mozilla is going to implement querySelectorAll by building on
that implementation. This will be done by testing each node in the set
of possible result nodes against the selector. So when we find a node
that matches "b", the implementation for ">" will walk the parent chain
and test each node against ":a". If we only want to test simple
selectors against descendants of the context node, then the ">" will
abort as soon as the context node is reached and say that the selector
doesn't match.
So we won't even reach the code for the "$self" or ":scope" or whatever
we call it.
This is certainly a solvable problem, but we would have to define very
precisely how matching is supposed to happen.
/ Jonas
