[css-anchor-position-1] Clarify how anchor-scope works with display:contents

[jjjalkanen]

The spec doesn't say much about how should anchor-scope be influenced by display:contents. Currently, it seems to be treated like any property which has no impact on anchor-scope - except when the scope element itself is also the anchor element.

[dshin-moz]

display: contents prevents that element from generating any box, so I imagine it wouldn't have any principal box.
anchor-name is applies to for all elements generating a principal box.
OTOH anchor-scope applies to all elements.

Strictly from above, I'd expect display: contents to have no impact on the behaviour of anchor-scope.
Both Chrome Canary (142.0.7401.0) and Safari TP (225, WebKit 20623.1.1.1) seem to ignore anchor-scope: all if we add display; contents to that element.

Implementation-wise, I think this means that, for anchor-scope specifically, we need DOM tree traversal, whereas we could get away with box tree traversal otherwise.

[emilio]

Does the dashed-ident version of anchor-scope apply to descendant boxes or descendant elements, and if the later, flat or light dom elements?

I think if we define anchor-scope as applying in the box tree, that answers the display: contents question and avoids asking new questions...

[tabatkins]

Per our resolution in #10325, everything in this spec operates on the flat tree (this is specified in the Values section of the intro).

That still leaves the question of elements vs boxes for anchor-scope. I'm inclined to say it cares about element relationships. We don't want, say, a top layer element to escape the anchor-scope of its parent just because top-layers are reparented in the box tree; this is somewhat necessary to make sure that popovers can reuse the same anchor-name in repeated components.