Composed tree infrastructure

[annevk]

The DOM Standard defines terminology for trees at https://dom.spec.whatwg.org/#trees, it defines terminology for crossing the shadow tree boundary at https://dom.spec.whatwg.org/#interface-shadowroot, but it doesn't define terminology around a tree that is composed of the light and shadow trees. It only does so indirectly for events.

Initially I thought this to be an adequate setup as CSS would take care of that, but it turns out other features also care about the composed tree, such as https://github.com/whatwg/html/issues/3821 (title attribute) and https://github.com/whatwg/html/issues/3699 (bidi; likely anyway). I suspect we'll need it for focus too.

And this would likely make things easier for CSS as well to define the flat tree.

(And for clarity, my understanding is such that a composed tree includes unassigned nodes (e.g., fallback), whereas a flat tree does not.)

cc @tabatkins @whatwg/components

[tabatkins]

CSS's tree needs are:

1. "tree of trees" - a DOM tree, with shadow hosts included and the shadows accessible. This is used for Selectors, as they only apply to a single tree context at a time, but need to be aware of ::slot() pseudos on shadow hosts, and the qualities of the host element and its ancestors for :host() and :host-context(). For CSS purposes, pseudo-elements are attached at this point.
2. "flat tree" - the above fully flattened, with shadows replacing light and slots filled in. This is also the "element tree" mentioned in Display. The conversion from DOM to flat tree is defined in Scoping.
3. box tree, and fragment tree, and some other trees that are all very CSS-specific

Where does this "composed tree" you mention fit in?

[rniwa]

The composed tree is the tree of trees. Features such as composedPath and Event's composed IDL attribute use the term to refer to that very concept.

I think adding the definition back to the DOM spec makes a lot of sense. I'm seeing that more and more features really need to refer to the composed tree, and not the flat tree because the latter doesn't have any of the nodes that were replaced by shadow roots but most of DOM APIs need to be well defined for all nodes, not just ones in the flat tree.

[hayatoito]

In the past, the Shadow DOM specification had a concept of composed tree, defined as a tree of trees, however, I remember we haven't migrated this concept into DOM Standard because we've found that definitions of shadow-including xxx (e.g. shadow-including ancestor) are good enough.

I guess we don't need a full concept of a composed tree any more. What we need here is a composed-parent or something for title attribute or bidi?

[annevk]

Indeed, I don't think we want an algorithm that produces a "composed tree" within which you can then traverse. We want specific traversal operations within the existing node tree, such as "composed-parent", "composed-child", etc.

[rniwa]

I think composed tree as a spec concept is still a useful thing. I do agree that the actual definition should really be done via composed-parent / composed-child relationship instead of some algorithm generating a new tree because composed tree is really just a way of traversing the existing DOM trees interconnected via shadow host/root.

[smaug----]

Yeah, I like the concept of composed tree, and at least in Gecko we very much have that, especially in the form of composed document (composed tree which has Document as the root).

[mfreed7]

I found my way to this issue as we're working on getComposedRanges() and I'd love to link to a definition of the "composed tree". AFACT nothing happened here, and DOM still doesn't have a definition of "composed tree". Is that right? Is there still appetite to define that term officially? E.g. somewhere here? https://dom.spec.whatwg.org/#trees

[annevk]

Yeah, we should still do this. I'm not entirely sure if a standalone "composed tree" concept would help as stated above as I think normative algorithms mainly want to get from one node to another.