Re: Support for matchesSelector()

On 4/10/11 4:32 AM, Lachlan Hunt wrote:
> 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.

Indeed.

> 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

That would be nice, yes.

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

I don't think so.

> 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 we're doing that right now.  ;)  In particular, discussing how 
that argument should work before actually implementing it.

I'd love for other UA vendors to chime in here if they've looked at this.

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

Yes, agreed.

> 1. Leave the spec as is and implement with the refElements parameter.
>
> This has the advantage of keeping the API simple.

Modulo defining the exact behavior of refElements, yes.

> 2. Create a more generic extension mechanism, such as an options
> parameter.

My gut feeling is that that's overdesign in this case.  But if we think 
we'll want to add namespace stuff soon (or at least at some point), 
maybe worth thinking about.

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

Indeed.

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

This seems like a good plan.

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

Let's not do that.

-Boris

Received on Wednesday, 13 April 2011 04:12:14 UTC