- From: Yehuda Katz <wycats@gmail.com>
- Date: Thu, 24 Nov 2011 10:53:24 -0800
- 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
- Message-ID: <CAMFeDTWdc2Y-bKKuu6gM1Whu2k8Kbog3cuE5q+bnA9S3DhscOw@mail.gmail.com>
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 UTC