W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Defining a constructor for Element and friends

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Tue, 13 Jan 2015 00:49:23 -0500
Message-ID: <54B4B1E3.10106@mit.edu>
To: Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
On 1/11/15 2:33 PM, Domenic Denicola wrote:
> "Terminology: In what follows I use 'own-instances of X' to mean objects where obj.constructor === X,

That doesn't make much sense to me as a useful test, since it's pretty 
simple to produce, say, an HTMLParagraphElement instance on the web that 
has whatever .constructor value you desire, right?  Unless the intent is 
to talk about this in some setup where no one has messed with any of the 
objects or something.

I guess the intent here is that we want obj to have been constructed via 
X in some sense?  Modulo whatever the story is for the things that have 

> as distance from 'instances of X' which means objects for which obj instanceof X."


Anyway, modulo exactly what this definition should be, let's talk about 
the proposed "the constructor of an element determines its set of 
internal slots" invariant.  I'm OK with that if we include "constructor 
arguments".  Otherwise, I don't see how it can make sense.  In 
particular, say someone does:

   var x = new Element("a", "http://www.w3.org/1999/xhtml")

or whatever argument order we do.  Per invariant 1 in your document, 
this should get the internal slots of an HTMLAnchorElement, right?  Per 
invariant 2, x.constructor == Element, and in particular x.__proto__ == 
Element.prototype.  So suddenly we have an HTMLAnchorElement as an 
own-instance of "Element", which I think violates your invariant 3.

Moving on to invariant 4, is that "instances" in terms on instanceof 
(which can be almost tautologically true, given what Web IDL says about 
[[HasInstance]] on interface objects), or in terms of what the proto 
chain looks like, or something else?  In particular, the "x" defined 
above doesn't have HTMLElement.prototype on its proto chain, but is 
instanceof HTMLElement...

>> I'd like to understand what you mean by "interface is Element" here, exactly.
> I'm just quoting Anne :). My interpretation is that the (object representing the) element is an own-instance of Element.

This _really_ requires pinning down what exactly own-instance means. 
Let's get our terminology in order.  ;)

The one piece of terminology that I think we have so far that I 
understand is what it means for an object to "implement an interface". 
At least Web IDL has a normative requirement on such a thing being 
defined (e.g. see http://heycam.github.io/webidl/#es-operations step 4 
of the behavior), presumably in terms of some sort of branding.

So it makes sense to me to talk about things implementing Element but 
not any interface that has Element as an inherited interface.  That 
would correspond to "is an Element but not any specific subclass of 
Element".  Could use a shorter way of saying it, for sure.

Received on Tuesday, 13 January 2015 05:49:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC