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

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.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Friday, 25 November 2011 07:50:22 UTC