[css-anchor-position] Flat tree vs. anchor-scope

[andruud]

The spec says anchor-scope scopes to "this subtree". It's not clear enough what we mean by that.

I suggest changing to "inclusive flat tree descendants".

@tabatkins

[fantasai]

See #8192 which is about similar concerns. Maybe we could re-use the wording.

(Probably this should be generalized into css-display.)

[andruud]

Proposed resolution: The anchor-scope property scopes to the flat tree

[astearns]

@fantasai do you agree with this wording?

[fantasai]

I think it's overly specific, and prefer using the wording from #8192 (comment) (as I said above). The way it's stated now it raises more questions about what else might be operating over the flat tree or not-flat tree.

[andruud]

@fantasai OK, so in other words, something like: features in this specification operate over the flattened element tree ?

[khushalsagar]

Scoping to the flat tree sounds like names in inner tree scope would be visible to the outer tree scope. This is not lining up with the resolution on #10145 (comment) where for view transition the lookup is tree scoped. And conversations on #10304 for a general policy for all CSS names.

Also @annevk specifically said by default all CSS names should be tree scoped as a general encapsulation principle for shadow DOM here: #10145 (comment).

[noamr]

We've discussed something related in view-transitions: #10145 (comment). To reiterate: we want to make sure that decisions about name encapsulation are consistent across these features.

Currently the direction for anchor positioning seems to be to use the flattened tree and have a CSS-based scoping property (anchor-scope). If this is the direction then we should do the same for view transitions, and revert the decision to have view-transition-names tree-scoped. CCing @fantasai, @nt1m and @annevk. I feel that having a consistent view about this problem from Apple would be very helpful to the discussion.

[andruud]

Not to worry @khushalsagar and @noamr, anchor lookup is already tree-scoped in the spec, and this issue does not change that. The anchor-scope property is an additional scoping mechanism that can only reduce the scope of things further. It does not change nor loosen the restrictions of tree-scoped lookups.

This issue is about exactly how to "look for" the anchor-scope-element. We either need to look at a given element's flat-tree ancestors, or the light tree ancestors. I do think we need the flat tree ancestors for this to work well, otherwise an anchor styled with ::slotted() can never be in an anchor-scope defined within the shadow root.
See https://github.com/web-platform-tests/wpt/blob/313fd03a0b/css/css-anchor-position/anchor-scope-shadow.tentative.html for an example where the distinction makes a difference.

[khushalsagar]

Hmmm yea, I misunderstood. When we say a name is tree scoped it means it can be used as a reference by elements in descendant/inner tree scopes. But a name in a descendant tree scope can not be referenced by elements in ancestor tree scopes.

This might be worth a note in the scoping spec.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position] Flat tree vs. anchor-scope, and agreed to the following:

• RESOLVED: "Like most operations in CSS besides selector matching, features in this specification operate over the flattened element tree." goes to anchor positioning spec.

The full IRC log of that discussion

<khush> andruud: the anchor-scope in the spec says it's scoped to this "subtree". flat tree or something else. matters for slotted. and i propose flat tree otherwise you can't style an element with ::slotted pseudo-element as an anchor.
<khush> andruud: if we don't use flat tree it's going to look for its anchor scope outside the shadow tree
<khush> Elika had an opinion on the exact wording
<khush> fantasai: idk if I understand the basic issue. i was concerned that we don't imply which tree here and other parts of the spec are ambigupus
<khush> just clarify that unless other specified the whole spec is operating on the flat tree
<khush> if we don't state this somewhere then its implied
<khush> astearns: agreed
<khush> somebody might skip that part and make assumptions about which tree rest of the spec is on
<khush> fantasai: in general css works on the flat tree. so this is more of a reminder
<khush> andruud: so already interpret it as a flat tree
<khush> astearns: is it extra work required at all?
<khush> astearns: proposed resolution is to add a normative statement to the anchor spec. Features in this spec operate over the flattened tree.
<khush> fantasai: there's wording i was suggesting to copy over from timeline lookups
<fantasai> "
<fantasai> Like most operations in CSS besides selector matching, features in this specification operate over the flattened element tree.
<fantasai> "
<khush> astearns: any concerns?
<khush> astearns: objections?
<khush> RESOLVED: "Like most operations in CSS besides selector matching, features in this specification operate over the flattened element tree." goes to anchor positioning spec.
<khush> astearns: good clarification to add
<khush> fantasai: most in case there are other exceptions
<iank_> sorry cant scribe - playing with solvents