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

Yehuda Katz
(ph) 718.877.1325


On Tue, Nov 29, 2011 at 11:06 PM, John-David Dalton <
john.david.dalton@gmail.com> wrote:

> > so maybe we don't need a matchesSelector then?
>
> We totally need a matchesSelector. It's perfect for event delegation.
> In Diego Perini's NWMatcher his `match` method is what drives the lib.
> https://github.com/dperini/nwmatcher/blob/master/src/nwmatcher-base.js#L391


I totally agree that we need the feature. This discussion was only about
what to name it. The matchesSelector name fits better with
querySelectorAll, while bare matches fits with the proposed find/findAll
(which would be properly scoped).

Since I'm in favor of the find[All] APIs, I am also in favor of the matches
name :)


>
>
> Though he avoids the matchesSelector API at the moment because the
> cost of testing/avoiding cross-browser bugs kills any perf gains.
>
> https://github.com/dperini/nwmatcher/commit/10a48ac54c3673c125c540447bb74c75cd1a9ed4
>
> -JDD
>
> On Tue, Nov 29, 2011 at 10:26 PM, Yehuda Katz <wycats@gmail.com> wrote:
> >
> > 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
> >> >
> >> >
> >>
> >>
> >
>