cc @hayatoito @rniwa

It seems this can operate on https://drafts.csswg.org/css-scoping/#flattening.

It's a little COMEFROM, but the Scoping section you point to is already defining that exact thing; after Selectors run on the DOM tree, the rest of CSS run on the flattened tree.

To be clear, OP is about CSS Display, which in https://drafts.csswg.org/css-display/#intro doesn't seem to talk about this. Am I still missing or did you miss which module the feedback was on?

That's why I said it's a bit COMEFROM-y - Scoping describes how shadow trees work within CSS at all, and in particular, says that the rest of CSS, post-Selectors, works on the flat tree, which it describes how to construct.

The rest of CSS, then, doesn't need to mention anything special - if you apply Scoping, then you work over the flat tree automatically. As far as Display is concerned, the flat tree and a DOM tree without any shadows are identical.

I see, I'd much rather have this be (much) more explicitly defined.

(I also wonder how does setup works when you need to map back from a box to an element in the tree for the various layout APIs?)

Can we list all the tree definitions and the precise algorithms to generate them in a single place?

My understanding is that at least there are

• The DOM tree
• The flat tree, obtained from the DOM tree by taking shadow DOM into account
• The element tree, which is like the flat tree but removing all non-text and non-element nodes, and adding tree-abiding pseudo-elements
• The box tree, obtained from the element tree according to the kind of nodes and their display types.
• And then boxes can be broken into fragments, so not sure if there is a fragment tree or if it's a dag or something like this.

(I also wonder how does setup works when you need to map back from a box to an element in the tree for the various layout APIs?)

I don't see anything troublesome about this. Flat-tree construction doesn't introduce anything that wasn't already present in the DOM, it just rearranges and excludes some bits.

@Loirooriol That's pretty right, yeah. The timing of the placement of the tree-abiding pseudos isn't super well-defined, but the difference isn't really important or exposed. And yeah, fragments form a fragment tree.

Going from the element tree => box tree => fragment tree is defined in https://drafts.csswg.org/css-display/#intro. It's the prior steps that are distributed across Selectors and Scoping in a way that requires you to know how they fit together a priori.