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

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

From: Alex Russell <slightlyoff@google.com>
Date: Wed, 19 Oct 2011 01:14:50 +0100
Message-ID: <CANr5HFXUcJgWEBKEkfS739qYT=SR_RYvD+UwXAGgSVusf6OV3Q@mail.gmail.com>
To: Sean Hogan <shogun70@westnet.com.au>
Cc: Yehuda Katz <wycats@gmail.com>, Webapps WG <public-webapps@w3.org>, John Resig <jeresig@gmail.com>, Paul Irish <paulirish@google.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>
On Wed, Oct 19, 2011 at 12:46 AM, Sean Hogan <shogun70@westnet.com.au> wrote:
> On 19/10/11 7:20 AM, Yehuda Katz wrote:
>>
>> I agree entirely.
>>
>> I have asked a number of practitioner friends about this scenario:
>>
>> <div id="parent">
>> <p id="child"><span id="inline">Content</span></p>
>> </div>
>>
>>  document.getElementById("child").querySelectorAll("div span"); // returns
>> #inline
>>
>> In 100% of cases, people consider this behavior *broken*. Not just
>> "interesting, I wouldn't have expected that", but "who came up with that!?".
>> In all cases involving JavaScript practitioners, people expect
>> querySelectorAll to operate on the element as though the element was the
>> root of a new document, and where combinators are relative to the element.
>>
>
> It matches the definition of CSS selectors, so I don't think it can be
> called broken. For this case, node.querySelectorAll("div span") finds all
> span's (in document order) which are contained within the invoking node and
> checks that they match the selector expression, in this case simply checking
> they are a descendant of a div.
>
> The new definition being promoted is:
> - start at the containing node
> - find all descendant div's
> - for every div, find all descendant span's.
> - with the list of span's, remove duplicates and place in document-order
>
> Once you understand the proper definition it is hard to see this new
> definition as more logical.
> To me, the problem here is some (not all) Javascript practitioners not
> learning the proper definition of CSS selectors.

I'm just going to assume you're trolling and not respond to anything
else you post here.

>> We already knew this was true since all JavaScript libraries that
>> implement selectors implemented them in this way.
>>
>
> To me, this indicates that there's no problem here. If you want to use an
> alternative definition of selectors then you use a JS lib that supports
> them. If you want to use the DOM API then you learn how CSS selectors work.
>
> I don't see JS libs ever calling the browsers querySelectorAll (or even a
> new findAll) without parsing the selector string first because:
> - JS libs support selectors that haven't been implemented on all browsers
> - JS libs support selectors that are never going to be part of the standard
>
> Since JS libs will always parse selector strings and call qSA, etc as
> appropriate, I can't see much benefit in creating DOM methods that accept
> non-standard selector strings.
>
> Sean
>
>
Received on Wednesday, 19 October 2011 00:15:45 GMT

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