18513 2012-08-09 21:51:10 +0000 [Shadow]: Consider re-projecting children in nested shadow DOM subtrees 2012-10-18 20:25:53 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 19436 18428 1 dglazkov dglazkov dominicc hayato shinyak sjmiles sorvell public-webapps-bugzilla oldest_to_newest 71993 0 dglazkov 2012-08-09 21:51:10 +0000 Consider this scenario: For Shadow DOM subtrees A and B, with A nesting inside B, there is an insertion point IPa in tree A that matches some (or all) children of the shadow host [Ah]. At the same time, an insertion point IPb in tree B is positioned as a direct child of A. The shadow host [Bh] of tree B has one child C. [Bh] -- B | | C [Ah] -- A | | IPb IPa The question is this: 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], which is a bit weird, since it seems logically like it should follow the same rendering rules as any other children of [Ah] 71994 1 dglazkov 2012-08-09 21:56:28 +0000 I suck at text diagrams. 71995 2 sorvell 2012-08-09 22:09:20 +0000 Since A exists for Ah, C will not actually be rendered since it is replaced by A. 71996 3 sjmiles 2012-08-09 22:12:12 +0000 For clarity, Steve Orvell's comment refers to the behavior of the current spec, not the proposal. 71997 4 dglazkov 2012-08-09 22:14:09 +0000 That seems like a sucky behavior, then. 71998 5 dglazkov 2012-08-09 22:14:33 +0000 For clarity, my last comment refers to the spec, not the proposal. 72097 6 dominicc 2012-08-13 04:54:13 +0000 (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. 72448 7 dglazkov 2012-08-20 21:45:50 +0000 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. 72890 8 dglazkov 2012-08-28 17:30:53 +0000 (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. 75324 9 dglazkov 2012-10-04 22:40:41 +0000 http://dvcs.w3.org/hg/webcomponents/rev/06da13b003eb 75325 10 dglazkov 2012-10-04 22:55:13 +0000 http://dvcs.w3.org/hg/webcomponents/rev/16e7f84e5f88 75326 11 dglazkov 2012-10-04 22:57:30 +0000 http://dvcs.w3.org/hg/webcomponents/rev/418286b9a95e 75421 12 dglazkov 2012-10-05 22:12:50 +0000 Grr. In order to correctly specify behavior of the adjusted parent algo, I need to add an extra input (and output) for context node. 75424 13 dglazkov 2012-10-05 22:32:21 +0000 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. 75425 14 dglazkov 2012-10-05 22:34:06 +0000 Unless, of course, we simply skip <D> <F> <I> from the ancestor chain. 76609 15 dglazkov 2012-10-18 19:55:33 +0000 http://dvcs.w3.org/hg/webcomponents/rev/6da10e050ff8 http://dvcs.w3.org/hg/webcomponents/rev/1607d5afd8af 76612 16 dglazkov 2012-10-18 20:25:53 +0000 yay.