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
