Bug 310398
| Summary: | [css-anchor-position-1] Accommodate pseudo-elements when sorting anchor elements by tree order | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Kiet Ho <kiet.ho> |
| Component: | Layout and Rendering | Assignee: | Kiet Ho <kiet.ho> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | bfulgham, kiet.ho, maikelkrause, santoshpavan.666, simon.fraser, webkit-bug-importer, zalan |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://github.com/web-platform-tests/wpt/pull/58900 | ||
Kiet Ho
[css-anchor-position-1] Accommodate pseudo-elements when sorting anchor elements by tree order
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/173032203>
maikelkrause
Relevant test: https://codepen.io/maikelkrause/pen/raMOVNN?editors=1100
The second (purple) chain uses `::after` pseudo-elements anchored to one another.
Kiet Ho
If there are multiple matching anchors with the same, the spec says we should sort them by tree order and take the last one.
The bug is that the current sorting code can't figure out which pseudo-element is before another pseudo element. So if you have a chain like 1 <- 2 <- 3, and they both have the same anchor name, it's possible for 3 to chain to 1 or 2.
The behavior is sorta non-deterministic, so it's possible for 3 to chain to 2 sometimes and to 1 some other times.
Kiet Ho
Pull request: https://github.com/WebKit/WebKit/pull/61306
Kiet Ho
Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/58900
EWS
Committed 310407@main (8c2cc6504c16): <https://commits.webkit.org/310407@main>
Reviewed commits have been landed. Closing PR #61306 and removing active labels.
santoshpavan.666
(In reply to Kiet Ho from comment #0)
> [css-anchor-position-1] Accommodate pseudo-elements when sorting anchor
> elements by tree order
>CSS Anchor Positioning (from the css-anchor-position-1 spec) handles pseudo-elements like ::before and ::after during anchor retrieval by treating them as implicitly anchored to their originating element, unless explicitly overridden. When sorting potential anchors (via steps like checking layout order, top layers, and containing blocks), pseudo-elements qualify only if they're "fully styleable tree-abiding" (e.g., ::before, ::after), and the originating element often serves as the fallback in auto mode.
>Anchor Retrieval Basics
The spec sorts candidate anchors by criteria like flat tree order and containing block ancestry, laid out before the positioned element. Pseudo-elements don't disrupt this; their originating element steps in for implicit positioning (e.g., position-anchor: auto). This ensures stable retrieval even if pseudos are named anchors.
>Pseudo-Element Handling
Valid pseudos (e.g., ::before) use the parent as default anchor, avoiding retrieval conflicts. For multiples with shared anchor-name, DOM order picks the last (or nearest ancestor), but anchor-scope limits visibility per subtree. No special "accommodation" step exists—pseudos integrate via originating element fallback.
Practical Tips
Set position-anchor: none on unwanted pseudos (e.g., ::picker) to exclude them. Test in Chrome (full support); pseudos like ::marker may fail as non-styleable. Use unique names or scopes for complex sorting