Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

Yehuda Katz
(ph) 718.877.1325


On Fri, Nov 25, 2011 at 7:49 AM, William Edney
<bedney@technicalpursuit.com>wrote:

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

I'd be ok with querySelector/querySelectorAll/matchesSelector and
find/findAll/matches

As I have said, I personally consider qS/qSA to be implementation mistakes
and would like to see find and findAll replace querySelector[All] in all
cases, so maybe we don't need a matchesSelector then?


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