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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 19 Oct 2011 22:52:59 -0700
Message-ID: <CA+c2ei9tfa2jE6fB+0zgHVv-5oSq5rpnWAXyOSJA58aMB751KQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Ojan Vafai <ojan@chromium.org>, 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 10:08 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.

Exactly.

>>> 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
> already.)
> 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.

I'm not sure I understand what you are proposing here. Are you saying that

<div>
<style scoped>
:scope {
  background: green;
}
</style>
</div>

should set the background of the <div> green? This does seem intuitive
I agree, but it might also lead to strange behavior since the
rendering of the <div> will change once the stylesheet is parsed. In
other words, it's very easy to get flash-of-unstyled-content behavior.

/ Jonas
Received on Thursday, 20 October 2011 05:54:05 GMT

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