Re: QSA, the problem with ":scope", and naming

On 20/10/11 1:07 PM, Jonas Sicking wrote:
> On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell<slightlyoff@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.

Received on Thursday, 20 October 2011 06:14:45 UTC