- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Wed, 19 Oct 2011 11:34:53 +1100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Yehuda Katz <wycats@gmail.com>, 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 10:58 AM, Tab Atkins Jr. wrote: > On Tue, Oct 18, 2011 at 4:46 PM, 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. > Not at all. I'm not sure why you think this is somehow an "improper" > way to think about things. > > There are two ways you can "scope" a selector. The first is to filter > the results of a selector match to only those under a certain element > (what QSA does today). The second is to scope the entire selector to > only apply underneath the scoping element, which is what Alex is > proposing. > > An alternative view of this is that current QSA restricts the final > compound selector in a selector to match only elements in the scope, > while allowing the rest of the selector to match elements anywhere in > the document. Alex's proposal (and every other JS selector engine) > restricts all of the selector component to matching only elements in > the scope. > > There is nothing unnatural or improper about this. The fact that > every JS selector engine works in the latter fashion, and that JS devs > are regularly surprised by the former behavior, suggests strongly that > the latter behavior is the better default behavior. > > Based on discussion on the mailing list,<style scoped> will be > changing to the latter behavior as well, with the ability to invoke > the former behavior in the rare circumstances when you explicitly want > it. If it becomes part of the standard definition of CSS selectors then it can be supported by a query method. At that point the only discussion is for the name. However, in reading that thread I don't see any mention of selectors such as "> div > span". Did I miss something? Sean
Received on Wednesday, 19 October 2011 00:35:35 UTC