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

> 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

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

Received on Wednesday, 30 November 2011 07:06:57 UTC