Re: [w3c/webcomponents] Add `customElements.upgrade` (#710)

@annevk ran into this use case with a client. The use case was `foo-bar` definition blocking head. while `baz-bat` was `defer`ed in definition. Wound up causing strange race conditions with the upgrade process. We settled on covering all mutually exclusive positions:
1. parent defined before child. 
2. child defined before parent.

What worked was wherever the script is declared (pre/post body) the algo is this:

1. Collect all custom elements up to point and upgrade.
2. (Always) upgrade upon DOM insertion of a custom element.
3. Whether upgrade is successful or not fails silently and doesn't throw to the call site.

#3 is where the specs would usually 💥  but we were more lackadaisical.

To be clear this isn't an encouragement towards the spec. More trying to abide with implementation aligned as close to what we are doing here.

Super looking forward to movement in this space. Many of these problems have been solving for the past year. Love seeing this be revisted.

-- 
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/710#issuecomment-344256849