Re: [w3c/webcomponents] Expose shadowRoot on element internals (#871)

> @rniwa I see that, like you said, the custom element state isn’t set to "custom" till upgrade here. Using that as the condition does appear to prevent `someElement.attachInternals()`. But it looks like it would prevent attaching in the constructor, too.
> 
> In [Upgrade an element](https://html.spec.whatwg.org/multipage/custom-elements.html#upgrades), the state is set to “failed” at step 3 (weird, but the note explains it takes care of an early exit for reentrancy). At step 6 the constructor is added to the stack and at step 8, the constructor runs. It isn’t till step 10, though, that — [provided everything went swell](https://html.spec.whatwg.org/multipage/custom-elements.html#upgrades:custom-element-state-3) — it changes [from “failed” to “custom”](https://html.spec.whatwg.org/multipage/custom-elements.html#concept-upgrade-an-element-set-state-to-custom).
> 
> I think that `custom element state` doesn’t (currently) align with the point where attachment should become available (unless I’m missing something). The gist makes sense to me but maybe a distinct flag would be needed?

Oh right. I was thinking of the synchronous construction case only. We probably need to introduce a new custom element state like "precustomized" and set to it right before step 8.2 ("Let constructResult be the result of constructing C, with no arguments.") of [upgrading an element](https://html.spec.whatwg.org/multipage/custom-elements.html#concept-upgrade-an-element). Then the change I'm suggesting will check whether the custom element state is either `custom` or `precustomzied`.


-- 
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/871#issuecomment-677973554