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

On Thu, Oct 20, 2011 at 1:14 AM, Sean Hogan <shogun70@westnet.com.au> wrote:
> 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'd like to instead propose that we
>>> shorten all of this up and kill both stones by introducing a new API
>>> pair, "find" and "findAll", that are rooted as JS devs expect. The
>>> above becomes:
>>>
>>>   element.findAll(">  div>  .thinger");
>>>
>> I like the general idea here.
>>
>> 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.
>
> If find / findAll are added to the spec there should also be an equivalent
> of matchesSelector that handles implicitly scoped selector, e.g. "> div >
> .thinger". To aid discussion I will call this matches(), but I don't think
> it is a good final choice.

How would .matches() work? For .findAll we basically prepend a ":scope
" selector step where the :scope pseudo-class matches the element on
which .findAll was called.

If we did the same for .matches() then

elem.matches("foo")

would try to match elem against the selector ":scope foo" where
":scope" only matches elem and thus the selector only matches elements
which are descendants of the element on which .matches() was called.

In other words, .matches() would never match anything.

Clearly you must have some other behavior in mind as a function which
always returns false isn't particularly interesting.

/ Jonas

Received on Thursday, 20 October 2011 08:33:15 UTC