I suck at text diagrams.

Since A exists for Ah, C will not actually be rendered since it is replaced by A.

For clarity, Steve Orvell's comment refers to the behavior of the current spec, not the proposal.

That seems like a sucky behavior, then.

For clarity, my last comment refers to the spec, not the proposal.

(In reply to comment #0)
 > If C is matched by IPb and C is matched by IPa, is C rendered as child of:
> a) Ah
> b) A?
>
> As spec'd today, the answer is [Ah]

Can you clarify whether | is a sibling or child relationship? I am going to assume it is a child. Are A and B elements or ShadowRoots? I assume that they are *elements* because you mentioned C being rendered as a "child of … A" and since ShadowRoots are themselves not rendered, A must be an element.

If those assumptions are right*, this question does not make sense to me for two reasons:

First, whether C is matched by IPa or not is immaterial, since insertion points match the children of host elements. C is not a child of [Ah], thus, it is not matched by IPa.

Second, it is not possible for C to rendered as a child of [Ah] since [Ah] has Shadow DOM with a top-level element A, hence the only thing rendered as a child of [Ah] will be A.

My conclusion is that if C is rendered, it is rendered as the child of A. Whether it is rendered depends on whether IPa also matches IPb (you mentioned it matches C – whether it matches IPb in addition to that.)

> , which is a bit weird, since it seems
> logically like it should follow the same rendering rules as any other children
> of [Ah]

I think this is confusing distribution and rendering. As far as I can see the rules for distribution and rendering are being applied consistently.

* This doesn’t make sense to me under other plausible assumptions, so if I got the assumptions wrong, help me out here.

Here's the modification that would be necessary to make this happen.

Replace of (3) in tree composition algorithm with: 

For each child node of HOST
    Let CHILD be this node
    If CHILD is an insertion point:
        Add results of a tree composition algorithm of this insertion point's shadow DOM subtree to POOL
        Otherwise, add CHILD to POOL

Basically, this builds a recursive traversal of the nesting trees into the algorithm.

(In reply to comment #7)
> Basically, this builds a recursive traversal of the nesting trees into the
> algorithm.

Scratch that. I've done a bit more experimenting and this is not sufficient.

http://dvcs.w3.org/hg/webcomponents/rev/06da13b003eb

http://dvcs.w3.org/hg/webcomponents/rev/16e7f84e5f88

http://dvcs.w3.org/hg/webcomponents/rev/418286b9a95e

Grr. In order to correctly specify behavior of the adjusted parent algo, I need to add an extra input (and output) for context node.

For the tree structure:

A--[SrA]
|    |
B    +-C-----[SrC]
       |       |
       +-<D>   +--E-----[SrE]
                  |       |
                  +-<F>   +--G-----[SrH]
                             |       |
                             +-<I>   +--<J>


Where all insertion points select "B", we should have the following ancestors list:

B <D> <F> <I> <J> [SrH] G [SrE] E [SrC] C [SrA] A

It's easy to arrive at <D>. Now, in order to determine <F>, we need to know both:

1) <D>, the node for which we're determining the parent
2) B, the node that is being reprojected.

To summarize, we need the node that is being projected as the second argument for the adjusted parent parent algorithm.

Unless, of course, we simply skip <D> <F> <I> from the ancestor chain.

http://dvcs.w3.org/hg/webcomponents/rev/6da10e050ff8
http://dvcs.w3.org/hg/webcomponents/rev/1607d5afd8af

yay.