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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 20 Oct 2011 14:41:30 -0700
Message-ID: <CAAWBYDAFWEab_4t8bMLjfc_Bc1n-5fBMQFr6ZvBcyJubU7L-tA@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Ojan Vafai <ojan@chromium.org>, Jonas Sicking <jonas@sicking.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>
On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> On 2011-10-20 22:32, Tab Atkins Jr. wrote:
>> On Thu, Oct 20, 2011 at 7:23 AM, Boris Zbarsky<bzbarsky@mit.edu>  wrote:
>>> On 10/20/11 1:08 AM, Tab Atkins Jr. wrote:
>>>> Basically, the presence of :scope would turn off *all* the limitations
>>> That's a _really_ bizarre behavior.  So in this case:
>>>  foo.find(":scope + div, div")
>>> what all divs in the document would be found?  Or is the "oh, ignore the
>>> reference node except for matching :scope" meant to only apply on a
>>> per-selector basis inside the selector list?  That has its own issues,
>>> especially with performance (e.g. merging nodesets while preserving DOM
>>> order).
>> Per-selector basis; we're not talking about naive string manipulation
>> here.  Your example would return divs that are descendants or an
>> adjacent sibling of the scoping element.
> Not necessarily.  It depends what exactly it means for a selector to contain
> :scope for determining whether or not to enable the implied :scope
> behaviour.  Consider:
>  foo.find(":not(:scope)");
> If that is deemed to contain :scope and turn off the prepending of scope,
> making it equivalent to:
>  document.querySelectorAll(":not(:scope)", foo);
> Then it matches every element in the document except the context node.

This seems perfectly fine, since if you just want all the elements
*underneath* the scoping element, you can instead do the much simpler:


> Otherwise, if it we decide that containing :scope means that it contains a
> :scope selector that is not within a functional notation pseudo-element,
> then it would prepend :scope, equivalent to:
>  document.querySelectorAll(":scope :not(:scope)", foo)
> Then it matches all descendants of the context element.

This prevents us from doing things like ":matches(:scope, #foo)",
which seems potentially useful.  (Plus, :matches(X) should always be
equivalent to just X, possibly modulo specificity differences.)

> In the latter case, then it would only ever be possible for matches to be
> found as descendants, siblings or descendants of siblings of the context
> element.
> That would even be true in cases like:
>  foo.find("section:scope+div, div, ~p span, .x :scope>h1+span")
> With the selector pre-processing, that selector becomes
>  "section:scope+div, :scope div, :scope~p span, .x :scope>h1+span"

Unless you use the reference combinator or the subject indicator, or
something else we come up with in the future that lets us do more
complicated searching.

Received on Thursday, 20 October 2011 21:42:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC