Re: [SelectorsAPI] Thoughts on querySelectorAll

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" <jonas@sicking.cc>
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: "John Resig" <jresig@mozilla.com>, "L. David Baron" <dbaron@dbaron.org>, public-webapi@w3.org
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

Received on Thursday, 1 May 2008 13:04:33 UTC