This has been implemented both for template element and also for ShadowRoot in WebKit.

Note that I've made a non-normative comment about this in the template element spec. I suspect that maybe DOM needs to say something about this, but I'm not sure how to approach this.

Anne, what's your feeling?

Note that last statement under the template element section:

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#template-element

Lets keep this open until it's fixed then okay?

So it seems like in addition to checking the inclusive ancestors as is already done by the pre-insert and replace algorithms, we also need to check the inclusive ancestors of the object the tree is associated with.

Should we maybe introduce a new node that inherits from DocumentFragment that can carry that additional semantic as well as provide a pointer to the hosting element?

(In reply to comment #3)
> Should we maybe introduce a new node that inherits from DocumentFragment
> that can carry that additional semantic as well as provide a pointer to the
> hosting element?

When you say "provide a pointer" do you mean as part of its interface? The WebKit implementation of course does exactly what you describe (a DocumentFragment subclass, a pointer to the host <template>) but doesn't change at the WebIDL level.

Well the idea was a new interface as the functionality might be useful. But I guess for now I can add a concept to DocumentFragment named "host" and then add the appropriate checks to pre-insert and replace in case there's a DocumentFragment root which has a host defined. Would that work?

@Anne, I like your solution in comment 5.

It seems like we should avoid exposing |host| as an IDL property until we have a clear use case.

If someone appends <template>.contents (or whatever that's called), that should just work right?

(In reply to comment #7)
> If someone appends <template>.contents (or whatever that's called), that
> should just work right?

Yes, that'll simply remove everything from the content fragment and append it to wherever it got appended, as it works for any other fragment. But there's no way to "detach" the fragment from the <template> (its "host" property can't change).

https://github.com/whatwg/dom/commit/bc62c366536ace9fde6bbc9f0098d0f17a64aef1
http://dom.spec.whatwg.org/#concept-documentfragment-host

You can now use this host concept in the <template> specification.

@Anne: The language in pre-insert doesn't look sufficient to me. I think you need to recursively traverse host boundaries.

e.g.

<div>
  <template>
    <div>
      <template>

and append the outer div to the inner-most template.content.

https://github.com/whatwg/dom/commit/534a39839a8bb69b6cf57c7692fe16ead5b1bcb7

Thanks!

Ok. The spec now is clear that when the content document fragment is initialized, its host element is set to the template.

https://dvcs.w3.org/hg/webcomponents/rev/1671f8bac2df

I'm going to go ahead and close this and leave it to Anne to get the language correct in DOM about preventing hierarchy cycles.

Are you saying I did not fix it? I'm confused.

My bad. I didn't noticed that you had fixed it. Looks right to me now. Thanks!