Re: [w3c/webcomponents] Should custom elements be adoptable if so, how? (#512)

@rniwa

> I don't think we can decide what custom elements do without agreeing on what regular elements should do.

I disagree, but we can set that aside for now.

> That doesn't make any sense to me. An element doesn't suddenly get un-created just because it got inserted into a new document. e.g. an input element that gets adopted into a new document preserves the dirty value (see demo).
>
> Also, calling different constructors twice on the same element seems like an abuse.

These are strong points and I am unsure whta is best. Constructors are generally constructed with the invariant that they only execute on uninitialized objects. We're already stretching that greatly in the upgrade process, and running two different constructors on the same object pushes us pretty far, perhaps past the breaking point.

With that in mind, if we want to avoid running constructors twice, I see two options:

- Custom elements are modified carry around a pointer to their element definition. Thus, after adoption, mutations of the element will continue working, using the old element definition from the old window. This involves all the potential issues with running script in a no-longer-existing window, of course.
- We do nothing. Thus, after adoption, mutations of the element might coincidentally trigger the "wrong" callbacks, since the element's node document's window's custom element registry is used for lookups, and that might have an element definition with the same name as the element. Or it might not, in which case no callbacks fire.
  - In some ways this is not as bad as it sounds, if you think of an element as being defined by its tag name
  - But, the fact that the constructor from the new window will not have gotten a chance to run, even though attributeChanged etc. will do so, seems pretty darn bad. Maybe it could be salvaged with an adoption callback... but I'd almost rather just run the constructor...

These two options are not great either.

However, we really need to pick *some* semantics. We can't just say "we don't support adoption"; we need a constructive counterproposal for *how* we're going to not support adoption. I guess one would be throwing in any adoption that tries to adopt a custom element...

---
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/512#issuecomment-223634592