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

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

--- Comment #47 from Bobby Holley (:bholley) <bobbyholley@gmail.com> ---
(In reply to Dominic Cooney from comment #44)
> > As partially noted in comment 41, I believe there are two approaches that
> > would resolve Boris' worries about throwing midway through a recursive adopt:

> It is very common to adopt subtrees containing Custom Elements across
> documents. A typical web component's UI is cloned out of a template
> (template document) and adopted into the custom element's shadow DOM (main
> document.) So I don't think throwing is feasible.

Sorry - I meant that we'd throw only in the cases where the adopt crosses
globals. Sorry if that was unclear.

> I think we should look for a solution that doesn't involve a bad compromise.
> Basically, something that works for web developers and doesn't leak. I don't
> think these things are incompatible.

I agree, though I believe that we have significantly more creative freedom with
the Web Components spec than we do with concept-node-adopt. I don't see a way
to avoid leaking if we do (1).

(In reply to Blake Kaplan from comment #45)
> With web components, that gets even more complicated: removing the web
> component-added prototype is obviously a non-starter (we might as well
> detach the web component binding) and, given that, no matter what we do in
> this case will leak the "old" document/window.

This is why I think we shouldn't allow script to adopt bound nodes across
globals. The binding is tied to the document, so if you're using the binding,
you're tied to the document. If we do this, we won't leak.

> I'm also happy to jump on a call to discuss this.

You're in CA right now, right? That makes the three of us perfectly
geo-distributed at 8-hour intervals around the globe. This isn't
insurmountable, but I think we should continue async as long as it's working.
;-)

(In reply to Scott Miles from comment #46)
> But I believe it can be necessary for ergonomic concerns to trump leak
> robustness if the likelihood or total cost of the leaks, as a practical
> matter, is not significant.

If this were only about Custom Elements, I'd be less worried. But what we
decide here affects every cross-global adopt.

> One last thing: although it's tempting to try to omnibus improvements to
> document handling into this bug, I lean towards doing Occum's minimum from
> existing semantics. In other words, cross document node handling is already
> tricky, it may be better to fix that in isolation from Custom Elements.

I agree 100%. This is why I think we should just punt for cross-global adopts
of Custom Elements (by speccing that it throws or fails somehow either (A) or
(B) from comment 43 is fine by me). We can always revisit that later and make
it not throw if we come up with some idea of meaningful cross-global semantics
for Custom Elements.

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

Received on Friday, 18 October 2013 08:16:05 UTC