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

Re: Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)

From: Yehuda Katz <wycats@gmail.com>
Date: Thu, 24 Nov 2011 10:53:24 -0800
Message-ID: <CAMFeDTWdc2Y-bKKuu6gM1Whu2k8Kbog3cuE5q+bnA9S3DhscOw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Sean Hogan <shogun70@westnet.com.au>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
Yehuda Katz
(ph) 718.877.1325


On Thu, Nov 24, 2011 at 6:52 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Nov 24, 2011 at 12:50 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au>
> wrote:
> > On 2011-11-24 00:52, Yehuda Katz wrote:
> >>
> >> On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan<shogun70@westnet.com.au>
> >>  wrote:
> >>>
> >>> The alternative option (find / findAll / matches can accept explicit
> >>> :scope, but will otherwise imply :scope) seems to be where all the
> >>> ambiguity lies.
> >>
> >> What exact cases are ambiguous with "find/findAll/matches can accept
> >> explicit :scope, but will otherwise imply :scope"?
> >
> > The problems to be solved with automatically switching between implied
> and
> > explicit :scope are basically in determining what exactly counts as an
> > explicit :scope.  The answers to each of these has is trade off between
> > complexity and functionality, with the simplest option being always
> implying
> > :scope.
> >
> > * Is explicit :scope allowed at the beginning of each selector?
> >
> >  find(":scope>div");
> >  find("body.foo :scope>div");
>
> Anywhere within the selector.
>

Agreed.


>
>
> > * Does :scope inside functional pseudo-classes count?
> >
> >  find(":not(:scope)");
> >  find(":matches(:scope)");
> >
> > If yes, does the first match the whole document, only descendants, or
> > descendants plus siblings?
>
> Yes, I believe so.  The first matches the whole document except for
> the scoping element.  The second matches only the scoping element.
>

Agreed.


>
>
> > * If using an explicit :scope, can it match itself?
> >
> >  find(":scope") // Return null or the element itself?
>
> Yes, because selectors with an explicit scope are evaluated against
> the whole document.  (Selectors with an implicit scope are too,
> theoretically, though implementations can optimize.)  That example
> returns the element itself.
>

Agreed. This returns the element itself.


>
>
> > * Is :scope always implied if it begins with an explicit combinator other
> > than descendant, even if :scope is used elsewhere?
> >  find(">div :scope");
> >  find("+div :scope");
> >  find("~div :scope");
>
> Yes.
>

I think I would be ok with this case throwing, because all of the cases are
nonsense queries.


> > * There's also the general issue, not related to :scope, about how the
> > reference combinator affects the range of potential matches.
> >  label.find("/for/ input")
> >
> > Based on the above issues, what happens in this case?
> >
> >  foo.find(">label /for/ input+:scope~span)
>
> This is equivalent to prepending ":scope" to the selector, and
> evaluating it against the whole document.  In other words, it finds a
> span that is preceded by the scope which is immediately preceded by an
> input which is referenced by a label which is a child of the scope.
>
> So, the rules end up being very simple.  find always evaluates against
> the whole document.  If one of the selectors starts with a combinator
> or doesn't contain a ":scope" pseudoclass somewhere in it, ":scope" is
> prepended to it.  That's it.  With this, we make the most common cases
> (searching descendants/siblings) easy, while making the global case
> *also* easy.  There's a bit of intent-guessing when :scope is used in
> an indirect way, but I believe it's better to err on the side of
> simplicity and consistency there.
>

I am ok with this, but I am also ok with "find always evaluates against the
whole document.  If one of the selectors doesn't contain a ":scope"
pseudoclass somewhere in it, ":scope" is prepended to it."

I also thing we agreed that filtering selectors, in the case of implicit
scope, are applied on the :scope, not as a descendent of the :scope.

As I said above, since the cases of starting with a combinator are nonsense
queries (correct me if I'm missing something obvious), we can simplify the
rules even more and eliminate the case of "starting with a combinator *and*
has a :scope"


>
> ~TJ
>
Received on Thursday, 24 November 2011 18:54:18 GMT

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