Re: [csswg-drafts] [css-anchor-position] Details on "anchors-valid" (#10201)

The CSS Working Group just discussed `[css-anchor-position] Details on "anchors-valid"`, and agreed to the following:

* `RESOLVED: Only care about default anchor; rename to anchor-valid.`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> TabAtkins: `position-visibility` controls whether anchor-pos elements automatically hides itself in certain cases. Some values are simple to define<br>
&lt;emilio> ... `anchors-valid` is not so simple<br>
&lt;emilio> ... the ideal here is "if you have an element that's supposed to be anchor-pos'd to something, you don't want it to display if it doesn't have an anchor to refer to"<br>
&lt;emilio> ... simple case is easy enough, but what if it refers to multiple anchors<br>
&lt;emilio> ... couple questions that need clarification<br>
&lt;emilio> ... first one is does this care about any of the anchor references are invalid or all?<br>
&lt;emilio> q+<br>
&lt;emilio> ... if you're ok with some things being missing you should supply a fallback<br>
&lt;emilio> ... what is a required anchor reference?<br>
&lt;iank_> what about (min(anchor(--a1 top), anchor(--a2 top)) ?<br>
&lt;emilio> ... using it in a simpler way, `top: anchor(--foo)` is clearly an anchor reference to `--foo`<br>
&lt;TabAtkins> top: anchor(--foo bottom, anchor(--bar bottom));<br>
&lt;emilio> ... is ^ a single reference to `--foo`, two (`--foo` or `--bar`), or either?<br>
&lt;emilio> ... I think the most reasonable behavior there is `--bar`<br>
&lt;emilio> ... the other question was about the default anchor<br>
&lt;emilio> ... spec no longer refers to a default anchor<br>
&lt;emilio> ... probably rule we want to adopt for that one is the default is a required reference if there is a default anchor<br>
&lt;emilio> ... the other one is how fallback affects this<br>
&lt;emilio> ... you can affect this with fallbacks<br>
&lt;emilio> ... probably the set of required anchors is only calculated after fallback<br>
&lt;emilio> ... non-used fallbacks don't account for that<br>
&lt;fantasai> emilio: Per spec the anchor() functions are gone from computed value<br>
&lt;fantasai> emilio: and the fallback stuff runs once per frame during resizeObserver<br>
&lt;fantasai> emilio: I think it would be best to ? the default anchor<br>
&lt;fantasai> emilio: A lot of the other values are conceptually gone<br>
&lt;fantasai> emilio: Like if you set top to a pixel value, it's no longer a reference<br>
&lt;fantasai> TabAtkins: So you propose we only care about default anchor for this<br>
&lt;fantasai> TabAtkins: That solves all of these questions<br>
&lt;Rossen> ack emilio<br>
&lt;iank_> would it make sense to rename to default-anchor-valid?<br>
&lt;fantasai> TabAtkins: in that case we can skip the rest of this issue<br>
&lt;emilio> fantasai: more or less what ian said, should the name be `anchor-valid`?<br>
&lt;emilio> TabAtkins: yeah, the plurality is confusing then<br>
&lt;iank_> or `position-anchor-valid`<br>
&lt;Rossen> ack fantasai<br>
&lt;emilio> ... so proposal from emilio would be changing the name and definition to only care about if your specified default anchor exists<br>
&lt;emilio> ... and that's the only anchor we care about<br>
&lt;fantasai> PROPOSED: Only care about default anchor; rename to anchor-valid.<br>
&lt;kizu> Sounds good<br>
&lt;emilio> iank_: may make sense to call it `position-anchor-valid`?<br>
&lt;emilio> fantasai: `anchor-valid` is shorter and `anchor-*` is the prefix we use for things like `anchor-center`<br>
&lt;emilio> iank_: fair<br>
&lt;emilio> RESOLVED: Only care about default anchor; rename to anchor-valid.<br>
</details>


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


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

Received on Thursday, 2 April 2026 20:51:51 UTC