Re: [w3c/webcomponents] HTML element constructors need to Get(newTarget, "Prototype") (#560)

So the first thing to figure out is when these two behaviors could possibly be distinguishable. They can't if you use class syntax, because in that case `.prototype` is non-configurable. So I guess we're talking about the specific case of function declarations that use `Reflect.construct` in their body and whose `.prototype` is then changed after element definition.

The other thing to consider is consistency with other constructors, as you point out. [An example](https://jsbin.com/xulifenayi/edit?html,console,output) makes it clear that as you say, it's the current value of the `.prototype` property that is used when constructing new instances, not the original.

Another way of looking at this is, if we were to think about "self-hosting" built-in elements with custom elements, or even just making built-in elements constructible, what would their behavior be? I'd like to think that overwriting `HTMLParagraphElement.prototype` would mean that `new HTMLParagraphElement` or `<p>` elements would be created with the new prototype for everyone; this is an intrinsic part of the contract of the `new` operator and object creation in general. On the other hand, overriding `HTMLImageElement.prototype.connectedCallback` would not change the browsers behavior for fetching images when you connect the image to the DOM. This is all hypothetical, as `HTMLParagraphElement.prototype` is non-configurable and we haven't worked to add callbacks for all the connected/attribute changed/etc. behavior to any classes in HTML. But as a hypothetical, this makes sense to me.

All this together indicates to me that @rniwa's instincts are right and we should change the spec to use `new.target.prototype` at construction time, instead of looking up the stored prototype. And furthermore, to me this is not inconsistent with the desire to store the callbacks.

@dominiccooney @kojiishi, would you be able to change Blink's implementation to do the `new.target.prototype` lookup instead of using the registry? I have the start of a test case for the new proposed spec for you here, which Chrome Canary fails: https://jsbin.com/subogesoji/edit?html,console,output

Now, let's work on the details here. In particular, what should happen if `.prototype` has been set to null or a non-object? I think the correct thing to do is fall back to the prototype of the HTML constructor that is being extended, as that's consistent with what ES does ([as shown in this example](https://jsbin.com/xulifenayi/edit?html,console,output) which falls back to `Error.prototype`). We could also consider falling back to the prototype stored in the definition...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/560#issuecomment-243899213