Re: Support for matchesSelector()

On 2011-04-08 16:41, Boris Zbarsky wrote:
> On 4/8/11 6:44 AM, Lachlan Hunt wrote:
>> We are thinking that implementing with a prefix as
>> Element.oMatchesSelector() is unnecessary
>
> Well, one obvious question is whether we now have good reasons to
> believe that the name and number/meaning of the arguments won't change.

The name is highly unlikely to change.  There's never been any 
suggestion that matchesSelector is an inappropriate name and no requests 
to change it that I'm aware of.

>> 2. Using the :scope selector in existing implementations will throw a
>> syntax error.
>
> That seems, to me, like something that should prevent unprefixing, no?

The same issue will occur with any new selector that gets added in the 
future.  The only real difference between this and any other is that 
support for :scope will inherently imply refElement support.

>> This means that if a script in the future wants to use a selector with
>> :scope, they will still be able to detect whether or not a given browser
>> supports it using a try/catch block.
>
> Yes, but should it have to?
>
>> 3. The existing querySelector methods also don't have a prefix, but
>> selectors api 2 also extends those in the same way with refNodes. This
>> should not be a problem for those methods.
>
> This is true, for the reasons you described, but trying to use the new
> features for the existing methods does involve that try/catch pattern
> you noted. But should we really require its use for matchesSelector?
> There are obvious benefits to having matchesSelector support imply that
> :scope is supported too...

I'm not entirely sure what you consider to be obvious benefits.  Do you 
think authors should be able to do this?

if (el.matchesSelector) {
   // Confirms that browser supports :scope and refNodes
} else if (el.mozMatchesSelector) {
   ...
} else ...

Are there any other obvious benefits that I may be missing?

> I should note that the way the old methods were extended is somewhat
> worrisome: as soon as a UA implements the new refNodes thing we're stuck
> with it. So I really hope that either we're very sure that's what we
> want to do or that UAs are careful about implementing until we get to
> that "very sure" level. I'd prefer the former, since I've been
> considering implementing this stuff.

I'm fine with waiting till we're very sure, and I hope we can get to 
that stage soon.  Do you have any suggestions for how we could lower the 
risk of unforeseen problems in the future?

I think it makes sense for matchesSelector and querySelector to use a 
common API design and accept the same parameters.

As far as I know, there are a few options we have:

1. Leave the spec as is and implement with the refElements parameter.

This has the advantage of keeping the API simple.

2. Create a more generic extension mechanism, such as an options 
parameter.  Then define the method as

    matchesSelector(selector, options);

Where options is defined to take an object with various properties, like 
this:

options = {
   ref: [el1, el2], // Reference nodes
   ns: [...],       // Namespaces
   ...              // Other future extensions
}

This would allow for easier extensions in the future where the method 
just ignores unknown options, but at the expense of a more complex 
syntax.  It's not clear what the chances are of wanting more extensions, 
nor if it's worth the complexity cost to go down such a path now merely 
as a precaution.

2a. Initially do what the spec says (#1), and then if such extensions 
are wanted in the future, overload the method in a backwards compatible 
way to accept both an refElements or an options object (#2).  That is, 
if adding a 3rd parameter or introducing a new method is undesirable.

3. Introduce new methods every time we want to add a new feature.

This isn't the most scalable, but might be the best option when it comes 
to namespace support, if we ever decide it's necessary to support that. 
  I'd rather not have to do it for refElements, since it would mean that 
the existing methods and the new methods without refElements would be 
functionally identical.

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

Received on Sunday, 10 April 2011 11:32:45 UTC