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

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

From: Sean Hogan <shogun70@westnet.com.au>
Date: Wed, 19 Oct 2011 10:46:46 +1100
Message-ID: <4E9E0FE6.5050407@westnet.com.au>
To: Yehuda Katz <wycats@gmail.com>
CC: Alex Russell <slightlyoff@google.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 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.

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

Received on Tuesday, 18 October 2011 23:47:25 UTC

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