- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 02 Dec 2013 18:57:45 -0500
- 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
HTMLImageElement).
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
and
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.
-Boris
Received on Monday, 2 December 2013 23:58:17 UTC