W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2013

Re: Convenient way to create element and set its attributes at once

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 02 Dec 2013 18:57:45 -0500
Message-ID: <529D1E79.4090207@mit.edu>
To: François REMY <francois.remy.dev@outlook.com>, www-dom@w3.org
CC: "'Domenic Denicola'" <domenic@domenicdenicola.com>, "'Tab Atkins Jr.'" <jackalmage@gmail.com>
On 12/2/13 5:43 PM, François REMY wrote:
> This isn't true, at least in IE and FireFox.
> 1) new Image() instanceof Image == true

At least in Firefox, this partially because Image has a non-default 
@@hasInstance (and in particular has the same @@hasInstance as 

That's not what the WebIDL spec says to do right now, actually; it 
specifies a non-default @@hasInstance (in its ES5 [[HasInstance]] 
incarnation) for interface objects but not NamedConstructor constructors.

I can't speak to what IE does here.

> 2) new Image() instanceof HTMLImageElement == true

In fact, if you have a subframe, then:

   new frames[0].Image() instanceof HTMLImageElement == true


   new Image() instanceof frames[0].HTMLImageElement == true

in Firefox (this part _is_ currently specced in WebIDL).

> ± instanceof walks up the proto chain but then looks for the
> ± .constructor of the things on the proto chain matching the RHS.
> As far as I know, this also isn't accurate.

Er, you're right.

> | var T = function T() {}
> | T.prototype = HTMLImageElement.prototype
> | document.createElement('img') instanceof T == true
> And this is true in all browsers.

Indeed.  What happens for the default @@hasInstance is that you walk the 
proto chain and see if anything on your proto chain is RHS.prototype.

But you're right that given that Image.prototype == 
HTMLImageElement.prototype using them on the RHS of instanceof would be 
identical even with the default @@hasInstance.

Received on Monday, 2 December 2013 23:58:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:21 UTC