- 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