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

Re: Remaining Problems with Explicit :scope Switching in find/findAll

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 27 Nov 2011 07:44:00 -0800
Message-ID: <CAAWBYDAhFEo-jMuyZ6fbTt95LKQn=uNVJo8mOfCk_Mn4jHbKLw@mail.gmail.com>
To: Sean Hogan <shogun70@westnet.com.au>
Cc: Yehuda Katz <wycats@gmail.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Fri, Nov 25, 2011 at 1:42 PM, Sean Hogan <shogun70@westnet.com.au> wrote:
> On 25/11/11 5:53 AM, Yehuda Katz wrote:
>> Tab Atkins wrote:
>>> 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"
> Are you AGAINST findAll() always implying :scope at the start of each
> selector in a selector list, and leaving explicit :scope to
> querySelectorAll()?
> If so, why?

Yes, I am, for the same reason as Yehuda - I think querySelector() was
minted with subtly wrong semantics that make it overly difficult to
use, and believe that find() can replace it in all cases.  Thus, I
don't want to "leave" any cases to querySelector() if we can
reasonably handle them in find().

Received on Sunday, 27 November 2011 15:44:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC