Boris Zbarsky: > As a result, given a <div> object (call it "div"), > > div.[[Prototype]] === HTMLDivElement.prototype > HTMLDivElement.prototype.[[Prototype]] === HTMLElement.prototype > div.appendChild === HTMLDivElement.prototype.appendChild > > are all true, while > > div.appendChild === HTMLElement.prototype.appendChild > > is false. As a result, to change what the appendChild of a <div> is you > have to change it on HTMLDivElement.prototype.
Interesting. > Of course all of this is subject to change, and in fact is likely to change > some time in the not too distant future. > > To be honest, do we really think that specifying the exact prototype chain > is desirable? I wondered that myself, but it would help the case where script authors want to mess about with the prototypes of various objects. Perhaps it doesn’t need to be specified exactly, but with enough fixed down such that you could reliably assign to HTMLElement.prototype.appendChild and expect it to affect your div element. > How likely are UAs to rework the mappings between their native code > and ECMAScript to follow said spec? Fair point, and I don’t want to go writing mounds of text if nobody cares enough to implement it. I imagine the likelihood depends on how far the spec diverges from the implementation. How about for Mozilla, assuming something “sensible” was specified that allowed script authors to know in which prototype object methods from a particular interface are to be found so that they can overwrite them? -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
