Re: Selectors API IDL Issues
On 4/2/11 5:46 AM, Lachlan Hunt wrote: Right, I get that much, but that mail I linked to previously claimed this difference was somehow observable from scripts, but I don't see how. Scripts can tell which object on the prototype chain a property comes from pretty trivially, no? Most simply by asking each object on the proto chain has it as an own property. Since [NoInterfaceObject] means that no script can possibly see whether or not NodeSelector really exists, from a black box perspective I don't see how that has any effect on the implementation. Lack of a prototype object is a separate question from where on the prototype chain the property appears. But it does not add to Element.prototype; the method goes on the mixin prototype object. If that's the case, if the spec uses [NoInterfaceObject] and 'implements', does that mean the spec will disagree with WebKit, Gecko, IE and Opera's implementation of selectors API? It'll disagree with Webkit, IE, and Opera. It won't quite agree with Gecko, but it'll be somewhat closer to it. Note that we plan to change the Gecko implementation, because it's nuts. AFAICS, all of them expose the querySelector* methods on Element.prototype. Gecko also exposes it on HTMLDivElement.prototype, HTMLBodyElement.prototype, etc, etc. OK, what I need to know is before Chaals and I proceed with taking the spec to PR, should I a) wait for you to make these changes and then make whatever relevant IDL changes to Selectors API, or b) just use [NoInterfaceObject] and foo implements NodeSelector and publish that? You don't want to do the latter, imo. We really want these things to just live on Element and Document in the sane way, not on the immediate prototype of every single element class. For one thing, if you do the latter hooking it globally becomes a huge PITA. -Boris
Selectors API IDL Issues
Hi,
Presently, the IDL in Selectors API defines the NodeSelector
interface using [Supplemental, NoInterfaceObject].
I'm not quite sure why I have supplemental in there, but it seems to be
left over from an old edit that should have been removed, since
NodeSelector is not a pre-existing interface that this is supplementing.
So I will be removing [Supplemental] from the IDL when I make the
edits necessary to take the spec to PR.
It's also been brought to my attention that the use of
[NoInterfaceObject] may not be quite right either and I would like to
get clarification.
According to a mail from Cameron [1], the use of [NoInterfaceObject] and
the implements statement has an observable difference from defining a
Supplemental interface, though I originally thought there would not be.
I thought that the following were identical from a black box
implementation perspective:
1)
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
2)
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Element implements NodeSelector
(And similarly for Document and DocumentFragment, omitted for simplicity)
The querySelector methods should exist on Element.prototype, which does
seem to be what Opera, Gecko and WebKit do.
According to Cam's mail, that is what does happen in case #1, but is not
in case #2, as in the current spec, though I'm not sure why. So I would
like to get clarification whether that is in fact the case, and whether
[NoInterfaceObject] really is what I should be using here.
[1] http://lists.w3.org/Archives/Public/public-web-perf/2011Mar/0058.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Selectors API IDL Issues
On 4/1/11 4:51 PM, Lachlan Hunt wrote:
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
This adds another method to Element.prototype
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Element implements NodeSelector
This adds a new interface called NodeSelector and says that any instance
of Element must implement this interface. But it does not add to
Element.prototype; the method goes on the mixin prototype object. See
http://www.w3.org/TR/WebIDL/#host-object-mixin-prototype
[NoInterfaceObject] just means there is no window.NodeSelector.
-Boris
Re: Selectors API IDL Issues
Lachlan Hunt:
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
This adds another method to Element.prototype
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Element implements NodeSelector
Boris Zbarsky:
This adds a new interface called NodeSelector and says that any
instance of Element must implement this interface. But it does not
add to Element.prototype; the method goes on the mixin prototype
object. See
http://www.w3.org/TR/WebIDL/#host-object-mixin-prototype
Boris is right, that’s the difference, as it currently stands in Web IDL
(forgetting for a moment that [Supplemental] isn’t defined). What I
will do in the near future is implement the proposed changes to remove
multiple inheritance from Web IDL and add the “mixin prototype” concept,
which will allow you to specify the augment-an-existing-prototype
behaviour that [Supplemental] would have given you.
[NoInterfaceObject] just means there is no window.NodeSelector.
Yep. That’ll be the default for these mixin interfaces, too.
--
Cameron McCormack ≝ http://mcc.id.au/
