Re: [w3c/webcomponents] Custom Element - untrackable upgrade (#671)

Seems like whenDefined just resolving when all need-to-be-upgraded elements have been upgraded would prevent us prematurely setting properties. This would need to include _all_ instances of an element, even one in a template or otherwise, being upgraded without being in a document ([unlike spec](https://w3c.github.io/webcomponents/spec/custom/#custom-elements-upgrades-examples)). 

This would be okay, because if we were to make the element with `new SomeElement` form, then stick it into a template or anywhere not a document, it would be an instanceof the actual custom element.

So upgrading all elements not matter what is fine, to keep consistency, because other wise we have a combination of instances that are a custom element and some that aren't, even if all these instances haven't been put into a document yet.

It would be great if we could rely on whenDefined this way (so all existing instances are guaranteed to have been upgraded no matter where they are). To me, this seems more desirable for reliable programs than preventing elements from being upgraded until being in a document.

Does anyone prefer something from lazy upgrade that they'd rather not lose in order to have whenDefined be more reliable? So far my use cases lean (100%) towards having a reliable whenDefined.

(Note, if we upgrade elements in templates, still we should not call connectedCallbacks or attributeChangedCallbacks until they are in a document)

-- 
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/671#issuecomment-335536337