All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector().
As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, "That train has sailed, baby..." Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: > On 25/11/11 6:49 PM, Lachlan Hunt wrote: >> On 2011-11-25 01:07, Sean Hogan wrote: >>> On 24/11/11 7:46 PM, Lachlan Hunt wrote: >>>> On 2011-11-23 23:38, Sean Hogan wrote: >>>>> - If you want to use selectors with :scope implied at the start of each >>>>> selector in the selector list (as most js libs currently do) then you >>>>> use find / findAll / matches. >>>> >>>> The matches method will not change behaviour depending on whether or >>>> not there is an explicit :scope because it is always evaluated in the >>>> context of the entire tree. There is never an implied :scope inserted >>>> into the selector, so there will not be two alternative matches methods. >>> >>> If and when there is a need for a matching method that does imply :scope >>> (which I provided a use-case for in >>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) >>> then it could be called matches(). >> >> Oh, it wasn't clear that you were talking about a case involving explicit >> reference nodes before. >> >> But adding two separate methods that are only subtly different would add >> more complexity for authors, since the difference will not always be obvious >> where there is no explicit reference nodes supplied and they may get them >> confused. >> >> In fact, with a method that always prepends :scope, it could result in an >> unexpected result in some cases: >> >> e.g. >> >> root.matches("html.foo"); >> root.matchesSelector("html.foo"); >> >> These aren't obviously different, but when you consider that the first would >> always prepend :scope under your proposal, the first would unexpectedly >> return false, since it's equivalent to: >> >> root.matchesSelector(":scope html.foo"); >> >> This would happen whether the root element is the root of the document, or >> the root of a disconnected tree. >> >> We could instead address your use case by implying :scope if a refElement or >> refNodes is supplied. That way, if the author calls .matches() without any >> refNodes, they get the expected result with no implied :scope. If they do >> supply refNodes, and there is no explicit :scope, then imply :scope at the >> beginning. >> >> This approach would be completely backwards compatible with the existing >> implementations, as nothing changes until refNodes/refElement and :scope are >> supported. >> > > You mentioned this before, but anyway: > > el.matches("div span") -> ok > > el.matches("> div span") -> throws, because no :scope implied > > el.matches("div :scope span") -> ok, but can't match anything > el.matches("> div span", refNode) -> ok > el.matches("div :scope span", refNode) -> ok > > el.matches("div span", refNode) -> what does this do? How do you know that > the intention isn't to just ignore the refNode if there is no explicit :scope? > > I guess if you wanted this last behavior, you could call something like > /:scope\b/.test(selector) > before-hand and if it is false then not pass the refNode to matches(). > > I'm not sure if there are other problematic cases. > > Sean > >
