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

The only case I can think of where explicit scope might be useful would be
to filter out certain cases entirely:

    elem.findAll(":scope:visible div");
    elem.findAll("#contents :scope [data-foo]")

It's probably fine to just say that you should do a match first in that
case, given the additional complexity of remembering all the rules. Alex,
what do you think?

Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 25, 2011 at 2:33 PM, Sean Hogan <shogun70@westnet.com.au> wrote:

> On 26/10/11 7:51 AM, Tab Atkins Jr. wrote:
>
>> On Tue, Oct 25, 2011 at 1:47 PM, Sean Hogan<shogun70@westnet.com.au>
>>  wrote:
>>
>>> I think allowing explicit :scope in findAll() will be perpetually
>>> confusing.
>>> I can imagine someone looking at old code like:
>>>
>>>     e.findAll("div.foo span, div.bar :scope span")
>>>
>>> and asking themselves "what's the rule again? If there's :scope in the
>>> selector then there's no :scope implied? Or was that just on each single
>>> selector? Or is :scope always implied at the start of the whole selector
>>> list and that's why it's explicit in the second part? Dammit, why didn't
>>> we
>>> just use querySelectorAll() if we wanted explicit :scope?"
>>>
>> Using :scope explicitly at the beginning of selectors is necessary if
>> we want a sane way to have selector lists chain off of the scoping
>> element.  I'm okay with the string starting with a combinator when
>> it's a single selector like "+ foo", but not when it's a selector list
>> like "+ foo, + bar".
>>
>> ~TJ
>>
>>
> I didn't follow that. Why does findAll() need to support explicit :scope?
>
> It is simpler if querySelectorAll() supports explicit :scope and findAll()
> doesn't.
> Plus it means findAll() matches how js libs currently work.
>
> Sean
>
>