Clarify create an element assertion

[annevk]

@domenic in create an element we have:

Assert: result’s custom element state and custom element definition are initialized.

Can we improve this by saying custom element definition is non-null? And custom element state is "custom"? I think that should hold after a successful constructor call.

[domenic]

This is very subtle. I wrote several wrong answers to this question before arriving at the conclusion that, yes, I think this is true.

The case I was concerned about was.

customElements.define("x-y", class extends HTMLElement {
  constructor() {
    // super() intentionally omitted
  }
});

document.createElement("x-y");

In that case the Web IDL "construct" call does nothing to set the custom element state or custom element definition (since no [HTMLConstructor] spec code ran). So I thought the assert would fail. However, what actually happens is that https://webidl.spec.whatwg.org/#construct-a-callback-function step 12 throws, because result is not a platform object and so cannot be converted to HTMLElement.

Inserting a note to this effect would be helpful to future readers, I think.

---

So yes, if we make it past the construct step, we must have run the [HTMLConstructor] steps to completion. Which I believe means your suggestions hold.

It still might be worth building WebKit with such an assertion and then running the custom-elements/ WPT suite, just to check.

[domenic]

Actually, what about this case?

<script>
customElements.define("x-y, asBefore);
</script>

<x-y></x-y>

<script>
const failedCE = document.querySelector("x-y"); // upgrade failed so this has state "failed"

customElements.define("x-z", class extends HTMLElement {
  constructor() {
    return failedCE;
  }
});

const failedCE2 = document.createElement("x-z");
</script>

I haven't traced through what this will do all the way, but I'm pretty sure it will make it to the assert line in question with the CE state as "failed", not "custom".