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

The CSS Working Group just discussed `[css-anchor-position-1] Reusing the implicit anchor name on the nested elements`, and agreed to the following:

* ``RESOLVED: Add `position-anchor: match-parent` ``

<details><summary>The full IRC log of that discussion</summary>
&lt;JakeA> https://github.com/w3c/csswg-drafts/issues/8913#issuecomment-3883275011<br>
&lt;emilio> JakeA: I've written a summary<br>
&lt;emilio> JakeA: [reads from his summary]<br>
&lt;lea> q?<br>
&lt;lea> q+<br>
&lt;emilio> JakeA: so I think we should have explicit keywords for this so they are discoverable by authors<br>
&lt;emilio> astearns: are both parent and match-parent necessary?<br>
&lt;astearns> ack lea<br>
&lt;emilio> JakeA: match-parent seems necessary, not so sure for parent but it seemed to be useful<br>
&lt;flackr> q+<br>
&lt;emilio> lea: big +1 on the general functionality, though keywords need to be bikeshedded<br>
&lt;lwarlow> +1 I think the names need more bikshedding (but I agree with the idea)<br>
&lt;astearns> ack flackr<br>
&lt;emilio> JakeA: There are some other use cases like tabs where the background animates and such<br>
&lt;emilio> flackr: is the explicit inheritance necessary or can we make the popover establish a new root of sorts<br>
&lt;emilio> ... maybe making position-anchor inherited but I guess that wouldn't work...<br>
&lt;emilio> JakeA: there's this closest-implicit idea which crawls up the tree<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> fantasai: not sure we'd want to limit it to implicit anchor necessary<br>
&lt;emilio> q+<br>
&lt;emilio> ... if you have a explicit one that might be also useful<br>
&lt;emilio> ... the use case is for a pseudo-element, but that's the default behavior, so we'd just need match-parent behavior<br>
&lt;emilio> ... for more complicated things like grabbing an ancestor or so<br>
&lt;emilio> ... if you want to be able to name an implicit anchor it might be helpful<br>
&lt;emilio> JakeA: the explicit anchor case would just be `anchor-name: inherit`<br>
&lt;fantasai> s/anchor-name/position-anchor/<br>
&lt;emilio> ... in terms of what pseudos do with their parent maybe the ship has sailed on that?<br>
&lt;emilio> ... I still think it'd be useful to have `position-anchor: parent` for elements that aren't pseudo-element<br>
&lt;fantasai> scribe+<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> parent behavior on pseudo-elements isn't default behavior, right? you need to specify `auto` for that to work?<br>
&lt;fantasai> JakeA: I don't think so. It uses the same mechanism as popover. It just becomes the implicit anchor.<br>
&lt;fantasai> emilio: popover has something magic in the UA stylesheet<br>
&lt;fantasai> emilio: There's some opt-in that needs to happen, because of the back-compat issue.<br>
&lt;lwarlow> q+<br>
&lt;fantasai> emilio: There are some subtle things to define here<br>
&lt;fantasai> emilio: You want to look up the parent's scope ... [missed] might be invalid<br>
&lt;fantasai> emilio: In general I'm supportive of this, names maybe bikesheddable.<br>
&lt;fantasai> emilio: I think the whole point of limiting implicit behavior of pseudos ... we limited it to have an opt-in<br>
&lt;fantasai> JakeA: The opt-in is using position-area. It just becomes the implicit anchor.<br>
&lt;emilio> fantasai: the issue around compat was not about whether there's an implicit anchor or not, but the fact that having an implicit anchor forced you to have a different containing block for scroll containers<br>
&lt;emilio> ... that was the compat issue that we tried to fix<br>
&lt;emilio> ... there's some interesting ergonomics issues around that situation and that's a fairly recent decision<br>
&lt;emilio> ... but it wasn't about the implicit anchor itself but about the cb<br>
&lt;astearns> ack lwarlow<br>
&lt;emilio> emilio: ah, right, thanks for clarifying<br>
&lt;emilio> lwarlow: +1 to the idea<br>
&lt;emilio> ... I think match-parent is mostly what you want in most cases<br>
&lt;emilio> ... naming (parent vs match-parent) is not super-clear<br>
&lt;emilio> ... popover default stuff had different thing about compat<br>
&lt;emilio> JakeA: that's fixed, that was about auto margins<br>
&lt;emilio> lwarlow: maybe we could make match-parent the default?<br>
&lt;emilio> ... though there's no one-size fits all?<br>
&lt;emilio> ... maybe there shouldn't be a default at all<br>
&lt;emilio> q+<br>
&lt;emilio> JakeA: weakly agree with putting it on the ua sheet<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: Would rather be explicit about it. Could imagine, for example, that you want the pseudo-element to anchor to the popover itself<br>
&lt;lwarlow> Maybe just we do ::picker(select), ::scroll-marker-group { position-anchor: parent; } then everything else is opt in?<br>
&lt;fantasai> emilio: So not sure I buy the UA stylesheet thing.<br>
&lt;fantasai> emilio: I'm fine with adding some keywords here.<br>
&lt;fantasai> emilio: If we just add `match-parent` it's easy. If we also want `parent` it's maybe confusing.<br>
&lt;fantasai> emilio: Pseudos have automatic parent behavior atm<br>
&lt;emilio> JakeA: not sure the automatic parent behavior makes sense to me on all pseudos<br>
&lt;emilio> JakeA: we could resolve on adding a keyword on `match-parent` behavior<br>
&lt;emilio> ... because I think that shouldn't be in the UA sheet<br>
&lt;lwarlow> +1<br>
&lt;emilio> ... you need to opt-in whenever you need it<br>
&lt;emilio> fantasai: making that opt-in makes sense<br>
&lt;fantasai> astearns: so proposed to add match-parent<br>
&lt;lwarlow> I guess we can propose to add a keyword for this and then bikeshed the name in future<br>
&lt;fantasai> emilio: Can resolve to add keyword for match-parent behavior...?<br>
&lt;flackr> q+<br>
&lt;fantasai> astearns: Renaming things is always on the table, but match-parent is best we've got so far<br>
&lt;lwarlow> +1<br>
&lt;astearns> ack flackr<br>
&lt;fantasai> flackr: Mentioned earlier, what if you could create a named anchor from your implicit anchor.<br>
&lt;emilio> flackr: what if you could create a named anchor for your implicit anchor<br>
&lt;emilio> ... if we had that we wouldn't need match-parent right?<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> ... if we introduce match-parent we're stuck with it even if we solve it more generally<br>
&lt;emilio> fantasai: I think match-parent is common enough<br>
&lt;emilio> ... it'd be good to have regardless<br>
&lt;lwarlow> +1<br>
&lt;emilio> flackr: I buy that argument<br>
&lt;emilio> RESOLVED: Add `position-anchor: match-parent`<br>
</details>


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


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

Received on Wednesday, 18 February 2026 17:51:24 UTC