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
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/
Support for matchesSelector()
Hi,
The matchesSelector() method has been implemented by both Mozilla [1]
and WebKit [2], and we are implementing the same level of support for it
as they did (without support for :scope or refNodes parameter).
However, both Mozilla and WebKit opted to implement it using prefixed
methods, and I'm wondering if people from Mozilla and WebKit could
explain their justification for using a prefix?
We are thinking that implementing with a prefix as
Element.oMatchesSelector() is unnecessary because:
1. Using refNodes without using the :scope selector has no effect and
additional parameters are just ignored.
e.g. el.matchesSelector(a, [el1, el2]); works now as defined.
2. Using the :scope selector in existing implementations will throw a
syntax error.
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.
e.g.
try {
var x = el.matchesSelector(:scopea, [el1]);
} catch (e) {
// Use alternative technique here to check.
}
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.
Therefore, I would like to get feedback from others, particularly the
Mozilla and WebKit developers about this approach, and find out whether
Mozilla and WebKit will also consider dropping the prefix?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=518003
[2] https://bugs.webkit.org/show_bug.cgi?id=29703
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Support for matchesSelector()
On 4/8/11 6:44 AM, Lachlan Hunt wrote: However, both Mozilla and WebKit opted to implement it using prefixed methods, and I'm wondering if people from Mozilla and WebKit could explain their justification for using a prefix? Sure. In Gecko's case, we implemented in October 2009. The first spec draft that mentions matchesSelector appeared in January 2010. So at the time we were implementing, there was no indication that the name, the number of arguments, the meaning of the arguments, etc would not change as said spec draft was written. 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. 2. Using the :scope selector in existing implementations will throw a syntax error. That seems, to me, like something that should prevent unprefixing, no? 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 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. -Boris
Re: Support for matchesSelector()
On 4/8/11 6:44 AM, Lachlan Hunt wrote: 2. Using the :scope selector in existing implementations will throw a syntax error. On which note, it seems like :scope will first show up prefixed as well, right? -Boris
Re: Support for matchesSelector()
On 2011-04-08 18:22, Boris Zbarsky wrote: On 4/8/11 6:44 AM, Lachlan Hunt wrote: 2. Using the :scope selector in existing implementations will throw a syntax error. On which note, it seems like :scope will first show up prefixed as well, right? Yes, that's reasonable. In which case, do we just want to define :scope as matching the documentElement of the ownerDocument of the element in question? Fixed. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
