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

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

~TJ

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