- From: Alex Russell <slightlyoff@google.com>
- Date: Wed, 19 Oct 2011 01:14:50 +0100
- 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 UTC