Re: [webcomponents] Custom elements disconnected from a document should not be upgraded (#419)

We discussed this internally and came around to a position much closer to @rniwa's initial one. Upgrades become an in-document concept only. Thus:

- We remove the upgrade candidates map, and the auto-upgrade concept, entirely.
- We remove the `{ upgrade }` option to `document.registerElement` that I added recently.
- Upon inserting any node anywhere, we upgrade all its descendants:
  - This means crawling inclusive descendants to find elements that have custom element definitions and are not yet defined, and upgrading them (in tree order).
- Upon defining an element, we upgrade all descendants of the window's documentElement.

We could also consider adding the ability to upgrade an element or a tree; my strawman is `window.customElements.upgrade(element, { deep })`. All else being equal I would prefer to add this API, but if anyone objects we can leave it out.

This is less developer-hostile than it appears. The only scenario in which you would possibly be caught out is when:

- You are lazy-loading an element definition
- You are creating an element using that not-yet-loaded element definition
- You try to use the element in ways that depend on its API, before ever inserting it into the document
  - Note that this normally would not work anyway, since you're lazy-loading the element definition and thus unsure when it will be defined.
  - If you do wait for the element definition to load, _then_ the `upgrade()` API could solve your problem.

We think that as long as this scenario is clearly documented, it should not be too hazardous.

---
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/419#issuecomment-196984358