Re: [csswg-drafts] [css-anchor-position] Default alignment in center track. (#11803)

The CSS Working Group just discussed `[css-anchor-position] Default alignment in center track.`, and agreed to the following:

* `RESOLVED: Default alignment in the center track (single track), default alignment is 'center' not 'anchor-center'.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: i think we got the default alginment wrong for the center track<br>
&lt;TabAtkins> fantasai: you can be in the center track, or span two, or span all three<br>
&lt;TabAtkins> fantasai: with all three, you want anchor-center by default so you're connected to the anchor<br>
&lt;TabAtkins> fantasai: but when you're just in the center track, anchor-center tries to put you centered on the anchor even if you specify an inset<br>
&lt;TabAtkins> fantasai: if you are using an inset, tho, usually that means you're compensating for something<br>
&lt;TabAtkins> fantasai:<br>
&lt;TabAtkins> fantasai: so i think it makes more sense to actually center when we're in just the center track<br>
&lt;TabAtkins> fantasai: kizu posted an example where using center looks weird with the insets, but i think that's actually another bug in chrome, where anchor-center isn't paying attention to the insets properly<br>
&lt;kizu> q+<br>
&lt;fantasai> This makes a difference if the author applies asymmetric insets, e.g. given a 100px anchor, suppose there's a 10px inset on the right. Should the item be centered against the entire anchor, or against the inset area?<br>
&lt;astearns> ack kizu<br>
&lt;kizu> https://github.com/w3c/csswg-drafts/issues/12020<br>
&lt;TabAtkins> kizu: i think i prefer to account for inset-area more<br>
&lt;TabAtkins> kizu: if you're compensating for the dimensions of something, we should honor that<br>
&lt;TabAtkins> fantasai: [example time]<br>
&lt;TabAtkins> fantasai: anchor element, with two bits, a main and a extra bit on the right<br>
&lt;TabAtkins> fantasai: i want my abspos to be below the anchor<br>
&lt;TabAtkins> fantasai: i want to compensate for the right bit, i'm not centering on that<br>
&lt;TabAtkins> fantasai: so use some `right: 10px` to shrink my area to match excluding the right bit of the anchor<br>
&lt;TabAtkins> fantasai: so now my IMCB is a little smaller, centered on the "main" bit of the anchor that I want<br>
&lt;TabAtkins> fantasai: i think it should center in that remaining space<br>
&lt;TabAtkins> fantasai: current spec says to use anchor-center<br>
&lt;TabAtkins> fantasai: which'll ignore the insets, it's caring about the anchor itself not the IMCB<br>
&lt;TabAtkins> fantasai: so I think if the author is explicitly using an inset we should pay attention to that. default shoudl be center, not anchor-center<br>
&lt;bkardell> sounds reasonable<br>
&lt;fantasai> TabAtkins: In the overflow case, where abspos is larger than the IMCB.<br>
&lt;fantasai> TabAtkins: you're saying that it's a chrome bug?<br>
&lt;fantasai> fantasai: Yeah, it'll center against the anchor box, ignoring the insets<br>
&lt;fantasai> fantasai: and I think it should honor the insets<br>
&lt;TabAtkins> (in other words, it should decenter when it's wide enough to hit one edge of the IMCB)<br>
&lt;fantasai> TabAtkins: I don't think I have a strong opinion. Ian, do you have any compat concerns?<br>
&lt;fantasai> iank_: probably compat wise is fine, early enough<br>
&lt;fantasai> iank_: people are usually using top/bottom, not center<br>
&lt;fantasai> astearns: Roman, sounds ok?<br>
&lt;fantasai> TabAtkins: we're basically showing off his example<br>
&lt;fantasai> PROPOSED: Default alignment in the center track (single track), default alignment is 'center' not 'anchor-center'.<br>
&lt;fantasai> RESOLVED: Default alignment in the center track (single track), default alignment is 'center' not 'anchor-center'.<br>
</details>


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


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

Received on Thursday, 3 April 2025 18:08:53 UTC