On 7/17/15 2:03 PM, Travis Leithead wrote:
Something magical happens here. The use of super() is supposed to call
the constructor of the HTMLElement class—but that’s not a normal JS
class. It doesn’t have a defined constructor() method

Sure, but neither does Array. What super() actually does is get the prototype of the current constructor and call it. So in your case:

class CustomElement extends HTMLElement {
   constructor() {

it would call the HTMLElement constructor.

Now there's a slight problem here, which is that HTMLElement is not defined to have a constructor in the spec right now. We need to fix that, clearly, for this subclassing of elements with constructors stuff to make sense.

Also, as
has been pointed out, running the CustomElement constructor code
_/before/_ instantiating the actual element (at parse-time for example)

I'm not sure what "before" means here. In the hypothetical world in which we call the CustomElement constructor from the parser, the parser would do that, and get back an object. That would be the "actual element".

·Javascript classes are mutable—what if CustomElement’s proto chain is
mutated later?

Then you get something that may not be an HTMLElement when you construct via it. Obviously consumers who care (like the parser, perhaps; though it may only care about getting Element) would need to check and handle that problem.

1.Native [internal] element is created with appropriate tag name,
attributes, etc.

2.JS constructor is called and provided the instance (as ‘this’)

The only problem with that is what Anne pointed out: there are some proposed ES spec additions that would require that the initial JS object allocation take the subclassing bits into account to determine which immutable state it's preallocated with. Note that I'm not convinced that means we need to call JS from the parser; just that's the problem Anne is trying to solve.

Need to chew a bit on your XFooStartup proposal before I can comment on it intelligently.


Reply via email to