Re: [w3c/webcomponents] Move the check for HTMLElement and its subclass from customElements.define to construction timing (#541)

Hmm. So let me try to understand your proposed alternate fix. Consider the following:

```html
<!DOCTYPE html>
<bad-1></bad-1> <!-- (1) -->
<script>
  customElements.define("bad-1", HTMLElement);
  document.createElement("bad-1"); // (2)
  new HTMLElement(); // (3)
</script>
<bad-1></bad-1> <!-- (4) -->
```

So with your proposal of checking `new.target`, clearly (3) will throw.

The other cases are less clear, but I think they work... at some point they all call Construct(HTMLElement), which throws:

- For (1), that causes the upgrade to fail; the exception will be send to window.onerror
- For (2), that causes createElement to synchronously re-throw the exception
- For (4), that will cause the parser to fail, thus the parser will instead create a HTMLUnknownElement.

So I guess it works.

----

Can you also help me understand why this check would be easier to make at construction time, instead of at definition time? In both cases you need to compare a constructor (either `C`, or `new.target`) against the list of all constructors. In neither case can you check a constructed object, since no object has been constructed yet. It seems a bit more costly to do the check on every element creation too... That's part of why I think I came up with the currently-specced approach, of just prohibiting these `"bad-1" -> HTMLElement` associations from ever getting into the custom element registry in the first place.

-- 
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/541#issuecomment-239545381

Received on Friday, 12 August 2016 19:59:12 UTC