On Wed, 6 Jun 2007, Boris Zbarsky wrote:
>
> To be honest, do we really think that specifying the exact prototype
> chain is desirable? How likely are UAs to rework the mappings between
> their native code and ECMAScript to follow said spec?
Safari has had to implement this stuff in a Mozilla
Boris Zbarsky:
> As a result, given a object (call it "div"),
>
> div.[[Prototype]] === HTMLDivElement.prototype
> HTMLDivElement.prototype.[[Prototype]] === HTMLElement.prototype
> div.appendChild === HTMLDivElement.prototype.appendChild
>
> are all true, while
>
> div.appendChild ===
Cameron McCormack wrote:
This is probably not what browsers do in practice, though. For example,
Opera 9 has an addEventListener method directly on the Node interface
prototype object
What Gecko does is to put all properties for all the interfaces an object
implements onto the "closest" prot
Cameron McCormack:
> The same question could apply to multiple inheritance (which is allowed
> by OMG IDL, but AFAIK is not used in any of the DOM specs).
As Ian reminds me, SVG uses multiple inheritance extensively.
--
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED] ▪ ICQ
Hi everyone.
What should the prototype chain for an object that implements multiple
interfaces looks like? A single interface is simple enough:
NodeList = { an object }
NodeList.[[Prototype]] = Object prototype object
NodeList.prototype = { an object }
NodeList.prototype.[[Prototype]] =
> On 05/06/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>> Actually, it's important for compatibility and conformance with past
>> specs to throw INDEX_SIZE_ERR for some (but not all) properties
>> specced as taking unsigned but actually passed a negative value.
On Jun 5, 2007, at 6:29 AM
On Jun 5, 2007, at 6:29 AM, liorean wrote:
On 05/06/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
Actually, it's important for compatibility and conformance with past
specs to throw INDEX_SIZE_ERR for some (but not all) properties
specced as taking unsigned but actually passed a negative
Ian Hickson wrote:
>
> I've changed the spec so that if you navigate a top-level browsing context
> whose name has been set using window.name (which is the only way to set a
> name on a top-level browsing context as far as I can tell) to a new
> origin, then the name is reset.
>
Even bette
> On 05/06/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>> I think DOM properties (and sometimes methods and function arguments)
>> vary on this. Some use the raw ECMAScript ToString algorithm. Others
>> additionally map the null value to the empty string instead of
>> "null". Still others m
