This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
template == <template><div>Foo</div></template> clone = template.cloneNode(true); options for clone.content: 1) Empty document fragment; // new empty document fragment 2) template.content.cloneNode(deep); // clone of contents 3) template.content; // share the original's content (content is a reference to the same document fragment). Given that one likely use of <template> is templating libraries, and one motivator for supporting nested <template>s is nested iteration -- I'm concerned that option (2) would be very wasteful of memory, but provide no benefit for the use case (in fact many developers may not even think about the behavior, and woudn't notice a difference between (2) & (3). I'll put a stake in the ground and claim that the right behavior is (3) because it makes the naive thing conservative WRT memory and isn't obviously bad behavior. (2) can still be achieved with more work.
I don't think the argument to cloneNode() should have any effect on what happens to the "content" property; its meaning should be limited to whether the template's children are cloned (though of course template won't normally have any children, unless they've been added by script). As for what cloneNode should do about "content", it seems like sharing the original template's content DocumentFragment (Rafael's option (3)) is at odds with the whole idea of "cloning". It would be quite surprising if changes to a cloned node affected the node it was cloned from. (1) seems wrong, since the clone is semantically very different from the original. The closest existing HTML element here is <input>, which copies its "value" property (along with a few others). So I think that Rafael's option (2) is the right answer. The objection seems to be about memory efficiency in the case of a templating library. Perhaps we need to make content settable, rather than readonly? That would allow a library to clone templates manually, e.g., by creating a new <template> and setting its content property to that of the original.
So we talked locally about this further (also brought Ojan in the discussion). There is precedent for non-attribute state which isn't cloned, which includes scroll state and selection state. Adam, myself and Ojan are now of the opinion that the right answer is (1) Empty document fragment, with the following caveats: -This probably means that if a use case is doing a deep clone, it will likely do a parallel df.querySelectorAll('template') on the source and the clone, and then either clone contents or share contents, based on its needs. Choosing option (1) doesn't make either of these the default, and leaves open the option of later adding specific API for HTMLTemplateElement which makes one or both of these easier -We probably want to maintain the invariant that a template contents is inert, and we also want to be enable sharing of content between templates, therefore we propose making content read/write, but on write, the template enforces that the assigned documentfragment has the correct ownerDocument (and adopts it to the right document, if not). Thoughts?
Elliot added the commentary that there is an assumption with cloneNode(true) that the result is "dead" (e.g. event listeners are gone, canvas's are empty, etc...). I think not cloning or referencing the content of the original is consistent with this. I've removed any discussion of the behavior of cloneNode, thus the existing cloneNode algorithm will (by default) not operate on the content attribute (and the clone will initialize itself with an empty document fragment when referenced). http://dvcs.w3.org/hg/webcomponents/rev/91b77f44e7d8