[Bug 20567] Change [[Prototype]] for concept-node-adopt?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567

--- Comment #65 from Bobby Holley (:bholley) <bobbyholley@gmail.com> ---
(In reply to Dominic Cooney from comment #62)

> (Presaging your question about an event for this reparenting...) I was
> speculating that if there was a callback to say, hey, this element is
> switching documents so authors can do what they want (switch definitions,
> drop definitions, leak definitions) and are flexible about the timing of
> that (maybe the prototype swizzling happens slightly after the element is in
> the new document) that might be a workable solution. The problem is I'm not
> sure what authors need here.

Would detachedCallback fire in that case?

I'm certainly happy to add whatever callbacks we need here. But IIUC, the issue
is less that authors want to be notified about adoption, and more that state
during the detachedCallback in that case is confusing. We could certainly say
"if you want to be sure to hear when your document is removed from the DOM, you
need to have both a detachedCallback and an adoptedCallback". But that's
probably pretty annoying, and most developers will probably just skip it, and
get confused when their element disappears via an adopt.

> > Right. We're trying to spec the swizzling (or lack thereof, though I would
> > non-neutrally contend that this side is losing in light of the leak data).
> 
> I'm not sure I'd frame it in terms of winning and losing... UAs today behave
> differently in this area, whether by design or historical accident, and
> being compatible would be good. But if we can't come up with something
> workable for UAs then probably the incompatibility will continue to exist.

I don't think we're seeing eye to eye here. Here's how I read the sequence of
events in this bug:

(1) Anne proposes speccing prototype swizzling for concept-adopt-node (applying
to all DOM nodes, not just custom elements). Discussion ensues. bholley makes a
lot of noise about leaks.

(2) In comment 37, Domenic requests that we consider Web Components as a
stakeholder in this discussion. He reports that Web Components had trouble
defining the callbacks semantics for adoptNode, and punted on prototype
swizzling.

(3) bholley proposes special-casing Web Components by making it illegal to
adopt them.

(4) In comment 51, Dmitri expresses his dismay with (3), and says that we
should make Web Components behave as much like the rest of the DOM as possible.

(5) bholley provides Telemetry data indicating that prototype swizzling is
required in the general case to prevent unacceptably-large leaks.

(6) In comment 57, Domenic signals his intention to go back to work on the Web
Components spec to come up with a solution for custom elements.

Does this match your interpretation? If not, what am I missing?

> > But doesn't the prototype live in the window in which it was registered? How
> > can you free the IFRAME if the element's prototype still points to an object
> > in its scope?
> 
> Right, if something like that exists, the object would leak.

This is what I want to avoid, at least for non Custom Elements. In this
sentence, I read "if something like that exists" as "if a custom element is
adopted cross-global". Is that correct?


In the light of comment 56, I would wager that it is more likely than not that
swizzling will get specced for the DOM in general. If that does happen, the
options I can think of for Custom Elements are:
(A) Swizzle the prototypes. If a Custom Element with the same name been
registered the new scope, the prototype points to that. Otherwise, the element
loses its magic. This approach requires figuring out the semantics of
|detachedCallback|.
(B) Leave the prototype in the old scope for Custom Elements. This leaks, and
makes Custom Elements more special, but might be more friendly to web
developers.
(C) Forbid adoption. This is easy, but probably makes Custom Elements too
special to re-implement existing things like marquee.

I think (A) is the best option if we want Custom Elements to be first-class
citizens.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 16 January 2014 02:56:17 UTC