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

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 Friday, 25 November 2011 14:05:22 UTC