Re: [csswg-drafts] [css-anchor-position-1] More intuitive alignment defaults when using one-sided insets (#12512)

The CSS Working Group just discussed `[css-anchor-position-1] More intuitive alignment defaults when using one-sided insets`, and agreed to the following:

* `RESOLVED: When only one auto inset, 'normal' alignment with position-area resolves to the alignment that attaches to the non-auto edge.`

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> TabAtkins: we know old absolute positioning works<br>
&lt;ydaniv> ... single length made it act as if your specified you're hanged, and added some magic<br>
&lt;ydaniv> ... we no longer resolve auto's<br>
&lt;ydaniv> ...  with anchor positioning<br>
&lt;fantasai> They resolve to zero, rather than to remaining space<br>
&lt;ydaniv> ... if you were using that old magic, it's now broken<br>
&lt;ydaniv> ... you'll get shrunk<br>
&lt;ydaniv> ... fantasai suggested we restore that using the normal alignment keyword, so if you're doing normal alignment<br>
&lt;ydaniv> ...  it will restore the old behavior<br>
&lt;iank_> q+<br>
&lt;ydaniv> ... my opinion, don't care much, only that it works physical and logical<br>
&lt;ydaniv> ... so having normal handle this is fine, iank_ is also fine with this, happy to accept<br>
&lt;miriam> +1<br>
&lt;Rossen2> ack iank_<br>
&lt;ydaniv> iank_: had one thought, that alternate solution is to only coarce, if insets are 0, so if you set one inset it will stick to the ege<br>
&lt;ydaniv> s/ege/edge/<br>
&lt;ydaniv> TabAtkins: that would be directly restoring the old behavior<br>
&lt;ydaniv> ...  that means that everything anchor related won't work, would like to retain 0's behavior<br>
&lt;ydaniv> ... because your contain block fits inside you can't rely on containing block calcs<br>
&lt;ydaniv> iank_: fair enough<br>
&lt;ydaniv> TabAtkins: this is related to other topic, we would like to preserve  the ability to override things<br>
&lt;ydaniv> iank_: I don't like the difference between 1 and 2 values specified<br>
&lt;ydaniv> ...  I don't like the fact that if you don't specify position-area you get one behavior, and otherwise a different one<br>
&lt;ydaniv> ... but maybe that's fine<br>
&lt;ydaniv> fantasai: we could consider making the alignment work similar to inset, resovle to 0<br>
&lt;ydaniv> iank_: we had compat concerns here<br>
&lt;ydaniv> Rossen2: sounds like we have a proposal, anything else?<br>
&lt;TabAtkins> Tho this restores the *visible behavior* to be similar between position-area:none and not-none<br>
&lt;TabAtkins> it just changes the way some keywords resolve<br>
&lt;fantasai> PROPOSED: When only one auto inset, 'normal' alignment with position-area resolves to the alignment that attaches to the non-auto edge.<br>
&lt;ydaniv> TabAtkins: yes, correct<br>
&lt;ydaniv> Rossen2: objections?<br>
&lt;fantasai> RESOLVED: When only one auto inset, 'normal' alignment with position-area resolves to the alignment that attaches to the non-auto edge.<br>
</details>


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


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

Received on Wednesday, 30 July 2025 16:41:53 UTC