Re: [csswg-drafts] [css-anchor-position-1] Reusing the implicit anchor name on the nested elements (#8913)

Summary for the CSSWG meeting today:

## Implicit anchors and popovers

When a button declaratively shows a popover (via `popovertarget` or `commandfor`), that button becomes the popover's [implicit anchor element](https://drafts.csswg.org/css-anchor-position/#implicit-anchor-element).

The same happens when a popover is shown via `.showPopover({ source })` - the `source` becomes the implicit anchor element.

This is great, as it means you can position the popover relative to the activator, without needing to specify either `anchor-name` or `position-anchor`.

## Popovers and arrows

A very common pattern is to give popovers an arrow, pointing to something (in this case the activator).

<img width="546" height="205" alt="Image" src="https://github.com/user-attachments/assets/d7c99aac-6fa6-45df-9107-2bf5007cddd7" />

It's also common for the arrow to be independently anchored to the activator, so it isn't locked to a specific offset within the popover content box.

<img width="537" height="202" alt="Image" src="https://github.com/user-attachments/assets/3245b52c-7668-47f6-895e-4cda14ce5bcf" />

An easy way to do the arrow, is to use a `::before` or `::after` pseudo of the popover. However, there's no way to tell the pseudo that its anchor is its originating element's implicit anchor element.

That was raised in this issue, and as a result some (and later all) pseudos [inherited the implicit anchor from the parent](https://github.com/w3c/csswg-drafts/pull/9037).

## But the fix was unfixed

In https://github.com/w3c/csswg-drafts/issues/11792, there was discussion around making `::scroll-marker-group` and `select::picker(select)`'s implicit anchor their originating element. This was later extended to all pseudos. This breaks the change made to support this feature.

I'm pretty certain this change was made in error, from these comments:

> It's technically a behavior change, but only with regards to content that is setting the anchor-pos properties *on* pseudo-elements *without* setting a `position-anchor` value. That seems vanishingly unlikely at this point in the feature's life.

and

> Right now if you don't specify a position-anchor, all of your anchor references just wouldn't work

This issue was raised with me by a developer who thought Firefox was buggy, until I pointed out their demo didn't work in Chrome. Their demo used to work, before this change.

## Proposed solution: Use keywords where possible, rather than implicit anchors

In the case of things like popovers, implicit anchors seem like the least-worst solution, since their value is dynamically set on interaction and JS calls.

However, we should avoid using them in cases where the relationship can be derived from the tree.

- `position-anchor: parent` - the element's parent (the originating element for pseudos) becomes the anchor.
- `position-anchor: inherit-parent` - inherit the anchor from the parent, including any implicit anchor. Alternatively, `closest-implicit`, which gets the anchor from the closest ancestor with implicit anchor.

These could be used in the UA stylesheet, but I don't have strong feelings on that.

This leaves the door open to other keywords, e.g. anchoring inputs to labels.

-- 
GitHub Notification of comment by jakearchibald
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8913#issuecomment-3883275011 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 February 2026 09:33:16 UTC