Interaction between CSS and composed tree needs to be better defined

[rniwa]

Section 2.4 defines composed tree but its purpose and use isn't clarified in the section.

Also the following text refers to the concept of "formatting structure" but this is a concept defined in a non-normative section of CSS2.1.

Unless an element is in a document composed tree, the element must not appear in the formatting structure [CSS21] nor create any CSS box.

I think, we want to define the composed tree as the document tree in CSS instead. Otherwise definitions of sibling, ancestor, etc... in the CSS world wouldn't make sense.

[rniwa]

@hober @fantasai: does that make sense to you?

[hayatoito]

FYI. Maybe we should update this section:
https://drafts.csswg.org/css-scoping/#shadow-cascading

Yeah, there is a duplication there, which we must resolve.

[rniwa]

Okay, now I have a slightly clear picture of what's happening. My comment on #308 (comment) will clarify some confusion about this.

On the contrary to what I wrote here, we probably want to expose shadow DOM before composition as is to CSS because style rules and inheritance resolution need to be intimately familiar with shadow boundaries and the relationship between trees. We can't simply hand the composed tree to the style engine and let it all work. The style engine needs to know from which tree style rule came from, etc...

So, I think we should remove the entire section about the composed tree and how it's used and leave it to CSS Scoping to define what it does with shadow DOM in general. Shadow DOM spec then just needs to define what constitutes a slot and how nodes are distributed into the slot.

[hayatoito]

Thanks. Yeah, I agree that that's the ultimate goal we should achieve.

I'm now triaging all Shadow DOM v1 issues and make some of v1 issues into v2 if the interoperability risk between UAs is low. Please feel free to re-label with v1 if someone find an interpretability risk.

[hayatoito]

This issue looks obsolete. Closing.