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

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

--- Comment #43 from Bobby Holley (:bholley) <bobbyholley@gmail.com> ---
(In reply to Dominic Cooney from comment #42)
> And I don't know to what extent the cases discussed here cause leaks.

If we go with (1), then implementations will be required to keep the old global
alive as long as the adopted node exists in a live document.

> Maybe time spent reducing leaks is better spent elsewhere.

I would much rather leave this prioritization to vendors than mandate it in the
spec.

> > How about we just make adoptNode throw for any element with a
> > binding? I don't imagine anyone would complain too hard about that.
> 
> Boris argues that throwing is a bad idea:
> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=21485#c6> I agree.

As partially noted in comment 41, I believe there are two approaches that would
resolve Boris' worries about throwing midway through a recursive adopt:

(A) Don't throw when adopting ancestors of Custom Elements, but don't adopt the
Custom Elements either. They get ejected from the document, but they (and their
children) remain owned by the original document and don't appear in the subtree
handed to the new document.

(B) Maintain a bit at each node indicating whether that node has Custom
Elements in its descendants, and throw immediately when we try to adopt such a
node. We'd only have to do work to compute this bit when applying/removing
bindings and inserting/removing Custom Elements from the tree, neither of which
are performance-critical operations. The algorithm would be
O(TreeDepth*AverageChildCount), and very fast in practice.

> re: Comment 41, compatibility is one constraint. I don't think the absence
> of compatibility constraints gives us a free pass on developer ergonomics.

I am highly resistant to speccing memory leaks for the sake of developer
ergonomics - it is very unlikely that developers will understand, care, or even
notice the fact that adoptNode would increase memory footprint (not to mention
all the sites that already use adoptNode). So they ship, and then users blame
their browser for being bloated.

I feel strongly about this particular issue because the scope of the memory
leaks (all cross-global adopts) is much wider than the scope of the feature and
ergonomics they'd be supporting (leftView semantics for Custom Elements being
adopted cross-global).

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

Received on Thursday, 17 October 2013 08:20:28 UTC