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

Thanks for raising this. Good to have the discussion. /cc @dominiccooney 

> It seems inevitable to support adaptation but there was a big controversy the last time we discussed this, which was whether the prototype of an adopted custom element should be changed or not.

If I understand the current situation correctly, the DOM spec aligns with WebKit/Blink behavior. There seems to be an irreconcilable difference of opinion as to which behavior should be done and since it hasn't caused any compat issues everyone seems to be in an uneasy stalemate in that regard. (This is all unrelated to custom elements.)

For custom elements my thought was that we would not take an opinion on this question. If we don't do so, then adoption kind of falls into place automatically:

- Adopting should downgrade an element's status to "undefined" (so :defined doesn't match it and no callbacks fire anymore)
  - In WebKit/Blink, the prototype will stay the same as in the old window, as in the current DOM spec for adoption.
  - In Firefox/Edge?, the prototype will probably be changed to something like HTMLElement? unsure; that behavior is unspecced.
- Once adopted, inserting into a new document will try perform an upgrade
  - If there is no element defined with that name in the new document's window's registry, then things will be left as they were before (with different behavior in different browsers)
  - If there *is* such a definition, then this automatically causes proto-munging, as all upgrades always do. The end result will be the same in all browsers.

---
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-223420692