- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 08 Jun 2007 16:34:47 -0500
- CC: "Web APIs WG (public)" <public-webapi@w3.org>
liorean wrote:
> Is this the reason for:
>
> var
> div=document.createElement('div'),
> span=document.createElement('span'),
> text=document.createTextNode('What am I?');
> Function.prototype.call.call(div.appendChild,span,text);
> text.data+='\r\n'+text.parentNode.tagName;
>
> failing with an uncaught exception in Gecko but not in any other browser?
"Somewhat" ;).
It's all part and parcel of the way XPConnect maps things back and forth from
C++ to JavaScript in Gecko.
> dd=document.createElement('dd'),
> dt=document.createElement('dt'),
That's a side-effect of the fact that both of those use the same concrete class
at the moment. The same one as <span>, in fact.
> If so, is there any possibility of making that work?
Not in the current setup in Gecko.
> I can understand not allowing e.g. applying the same appendChild
> implementation to work on both Element and Attr objects, but not
> allowing it on other element objects seems a bit limiting to me.
The point is that the system doesn't know that the appendChild comes from
Element. All it knows is that a member method of one class is being applied to
another one, and that it doesn't allow that. As things stand, that is.
> Is there any compelling reason why
>
> HTMLElement.prototype.appendChild ===
> HTMLDivElement.prototype.appendChild
>
> isn't true in Gecko?
Define "compelling"? The basic reason is that this is how the generic JS-to-C++
mapping layer works. Changing how it works is not really much of an option for
compat and time reasons; the only quick way forward is to stop using it
altogether for DOM objects. Which might happen.
-Boris
Received on Friday, 8 June 2007 21:34:59 UTC