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

Received on Saturday, 2 April 2011 18:39:55 UTC