W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 20 Oct 2011 20:20:34 +1100
Message-ID: <4E9FE7E2.7030705@westnet.com.au>
To: Jonas Sicking <jonas@sicking.cc>
CC: Alex Russell <slightlyoff@google.com>, Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>, John Resig <jeresig@gmail.com>, Paul Irish <paulirish@google.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>
On 20/10/11 7:32 PM, Jonas Sicking wrote:
> 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
>
See the definition of matchesSelector(selector, [ refNodes ]) in the spec:
     http://www.w3.org/TR/selectors-api2/#matchtesting
Received on Thursday, 20 October 2011 09:21:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT