My deep dive into Anchor Positioning over the last two months—culminating in numerous Almanac entries and a comprehensive Guide—led me to believe the topic was finally settled. However, the CSS Working Group (CSSWG) continues to refine this evolving area, and recent telecon minutes revealed further developments.
The following resolution highlights a key advancement:
When comparing names, if at least one is tree-scoped, both must be tree-scoped, requiring an exact (not subtree) match. (Issue #10526: When does anchor-scope “match” a name?)
While not directly part of the specification, this resolution strongly suggests the future direction of anchor-scope. This provides an excellent opportunity to explore the implications of this resolution and other interesting points from the telecon. (Remember, you can subscribe to and read the full minutes on W3C.org.)
Understanding Anchor-Scope
Anchors, identified by anchor-name
, allow absolutely positioned elements (using position-anchor
) to attach to them. While anchor-name
doesn't need to be unique, reusing it within a component can lead to unexpected behavior. Without anchor-scope
, multiple anchors with the same name cause targets to stack on the last instance. The anchor-scope
property ensures that an anchor is only accessible to targets within its subtree.
For example:
.anchor { anchor-name: --my-anchor; anchor-scope: --my-anchor; /* Added for proper scoping */ } .target { position: absolute; position-anchor: --my-anchor; position-area: top right; }
This raises the question: what should the scope of anchor-scope
itself be? The CSSWG addressed this, originating from a GitHub issue highlighting three possible interpretations of anchor-scope
matching.
The CSSWG telecon discussion, particularly contributions from TabAtkins, khush, and fantasai, concluded that anchor-scope
should be tree-scoped. This decision extends to View Transitions, which also rely on tree scoping. The resolution was:
RESOLVED: Whenever comparing names, if at least one is tree-scoped, then both are tree-scoped, and the scoping must be exact (not subtree).
A further resolution clarified that the all
keyword in anchor-scope
(making all anchors tree-scoped) is also tree-scoped.
The discussion then shifted to the CSS Scroll Snap Module Level 2 draft and its scroll-start-target
property. This property allows specifying an element as the initial scroll target. The CSSWG addressed the scenario of multiple potential targets, resolving to use reverse-DOM order to determine the initial scroll position.
Finally, the group debated the text-underline-position: auto
value, deciding to add an auto
value to text-emphasis-position
and modify text-underline-position: auto
to handle left/right positioning in vertical text, aligning with existing browser behavior.
I highly recommend reading the complete minutes for a thorough understanding of the discussions and decisions. A summary of resolutions is also available.
The above is the detailed content of CSSWG Minutes Telecon (2024-09-18). For more information, please follow other related articles on the PHP Chinese website!