On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell<slightly...@google.com>  wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and ":scope". He asked me to continue here, so I'll try to keep it
short:

The rooted forms of "querySelector" and "querySelectorAll" are mis-designed.


I like the general idea here. And since we're changing behavior, I
think it's a good opportunity to come up with shorter names. Naming is
really hard. The shorter names we use, the more likely it is that
we're going to break webpages which are messing around with the
prototype chain and it increases the risk that we'll regret it later
when we come up with even better functions which should use those
names. Say that we come up with an even better query language than
selectors, at that point .find will simply not be available to us.

However, it does seem like selectors are here to stay. And as much as
they have shortcomings, people seem to really like them for querying.

So with that out of the way, I agree that the CSS working group
shouldn't be what is holding us back.

I don't agree with Selectors API supporting invalid selectors, but I guess the discussion is more appropriate here than there.

However we do need a precise
definition of what the new function does. Is prepending ":scope " and
then parsing as a normal selector always going to give the behavior we
want? This is actually what I think we got stuck on when the original
querySelector was designed.

So let's get into specifics about how things should work. According to
your proposal of simply prepending a conceptual ":scope" to each
selector group, for the following DOM:

<body id="3">
   <div id="context" foo=bar>
     <div id=1></div>
     <div class="class" id=2></div>
     <div class="withChildren" id=3><div class=child id=4></div></div>
   </div>
</body>

you'd get the following behavior:

.findAll("div")  // returns ids 1,2,3,4
.findAll("")      // returns the context node itself. This was
indicated undesirable
.findAll("body>  :scope>  div")  // returns nothing
.findAll("#3")  // returns id 3, but not the body node
.findAll(">  div") // returns ids 1,2,3
.findAll("[foo=bar]") // returns nothing
.findAll("[id=1]") // returns id 1
.findAll(":first-child") // returns id 1

Is this desired behavior in all cases except the empty string? If so
this seems very doable to me. We can easily make an exception for the
case when the passed in string contains no selectors and make that an
error or some such.

I know everyone knows this, but...

These specific examples (where the selector is not a comma separated list) plus most instances of selector lists (e.g. "th, td", "> ul > li, > ol > li") can be trivially supported by a tiny wrapper around querySelectorAll() as defined in Selectors API v2. In fact, I've never seen a selector list that couldn't be successfully split on "," and I wouldn't be surprised if they are never used outside of stylesheets.

I do however like the idea that if :scope appears in the selector,
then this removes the prepending of ":scope " to that selector group.
Is there a reason not to do that?

1. Already supported (in the draft spec) by querySelectorAll().
2. Not supported by JS libs.
3. No use cases requiring it.

Additionally it seems to me that we could allow the same syntax for
<style scoped>. But maybe others disagree?

Surely it is both or neither. You don't want to set a precedent for DOM selectors not matching CSS selectors.

I think appropriate optimizations as well as extensible functions
should be out-of-scope for this thread. They are both big subjects on
their own and we're approaching 50 emails in this thread.



Reply via email to