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: Wed, 19 Oct 2011 22:08:29 -0700
Message-ID: <CAAWBYDC695nu6MRFjfi3sdsgJYE_=E1sDiJpCe1BW8myRPC_jQ@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: 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>, Lachlan Hunt <lachlan.hunt@lachy.id.au>
On Wed, Oct 19, 2011 at 7:22 PM, Ojan Vafai <ojan@chromium.org> wrote:
> On Wed, Oct 19, 2011 at 7:07 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> .findAll("body > :scope > div")  // returns nothing
> Wouldn't this return ids 1,2,3 if we're not prepending :scope as you say
> below?

Yes, but he was answering those questions based on the assumption of
always prepending :scope.

>> Additionally it seems to me that we could allow the same syntax for
>> <style scoped>. But maybe others disagree?
> Sounds good to me. A sticky case you left out is parent, sibling and
> reference combinators.
> .findAll("+ div")
> Assuming the context node has siblings, should that return them? If so,
> should it match siblings when using <style scoped>.
> IMO, it shouldn't match anything in either case. We should assert that
> only descendants of the scope element will ever be returned. This would also
> make it naturally match <style scoped> where only descendants of the scope
> element are ever affected.

I disagree.  It's extremely useful and natural for .find(":scope +
div") to match sibling of the context node.  Basically, the presence
of :scope would turn off *all* the limitations; the only thing that
the context node still does is match the :scope pseudo.  The selector
should match across and return elements from anywhere in the document.

This is where I think that .find and <style scoped> should diverge in behavior.

.find should have two cases:

1. Selector without :scope - run the selector only across the
descendants of the context node.  (No need to explicitly filter, since
the results will only contain descendants of the context node
2. Selector with :scope - run the selector across the entire document,
with :scope matching the context node.  (No filtering here, either.)

<style scoped> should (I think) have three cases:

1. Selector without :scope - same as .find
2. Selector with :scope - Same as #1, but also including the context node.
3. Selector in @global - run the selector across the entire document,
filter the results to only be the context node and its descendants.

(Some people disagree with me on this, and think that #1 and #2 should
be merged to always include the context node.  That's acceptable, but
I don't like it as much.)

I think it's perfectly okay that these two APIs have different cases.

Received on Thursday, 20 October 2011 05:09:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:45 UTC