Re: [csswg-drafts] [css-anchor-position] should alignment safety consider the containing block? (#10316)

The CSS Working Group just discussed `[css-anchor-position] should alignment safety consider the containing block?`, and agreed to the following:

* `RESOLVED: Accept proposal in 10316 but don't change normal behavior when not using inset-area`

<details><summary>The full IRC log of that discussion</summary>
&lt;keithamus> fantasai: this is a fun one, tackles two issues. Both anchor-center currently defined to changed the size, as well as to shift the alignment.<br>
&lt;keithamus> ... so, the proposal is to remove the special sizing behavior from anchor-center. When neither unsafe nor safe is specified in the alignment property - in other words by default. And only when its not normal<br>
&lt;keithamus> ... when the object is larger than the container we overflow away from the scrollable region<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/10316#issuecomment-2125437844<br>
&lt;keithamus> fantasai: So you're using the inset properties to create a containing block. If you're in abspos is small enough to fit in the IMCB you just do alignment as you specify<br>
&lt;keithamus> ... If its larger than the IMCB we don't make it start aligned. If you hit the edge, say the right edge, the point were it's big enough to break out of the containing block we overflow in the opposite direction<br>
&lt;keithamus> ... we overflow away from the scrollable region<br>
&lt;keithamus> ... what this does - it gets you a very nice behavior for anchor center<br>
&lt;TabAtkins> q+<br>
&lt;keithamus> ... that you keep the item visible. Try to center as much as possible but don't overflow unless you overflow the entire containing block<br>
&lt;keithamus> ... shift the area as much as you can<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/10315<br>
&lt;keithamus> ... the other issue is this one<br>
&lt;iank_> q+<br>
&lt;keithamus> ... a nice illustration somewhere<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/9960#issuecomment-1944518084<br>
&lt;keithamus> ... Una made a nice example of this<br>
&lt;keithamus> ... the second behavior, not the one that resizes<br>
&lt;Rossen4> ack TabAtkins<br>
&lt;keithamus> TabAtkins: the only thing is you can't apply to normal. So locked in on compat. We might try to not do this on start/center/end<br>
&lt;keithamus> ... there's large amounts of content that applies center to abspos things<br>
&lt;keithamus> ... we might need to disallow on those based on compat<br>
&lt;keithamus> ... we'll see how it goes when we deploy<br>
&lt;keithamus> iank_: a little concerned web devs will get confused<br>
&lt;keithamus> ... they say anchor center and the CB for some reason or another is small... I guess we might just have to teach webdevs to use unsafe anchor center<br>
&lt;keithamus> ... which probably isn't the worst<br>
&lt;Rossen4> ack iank_<br>
&lt;keithamus> ... but be prepared for likely recommending that heavily<br>
&lt;keithamus> TabAtkins: if you have a weirdly small CB the position try stuff will be affected to. So they'll have to learn<br>
&lt;keithamus> fantasai: the behavior we ideally wanted is you do safe centering if you're overflowing the edge of the scroll container<br>
&lt;keithamus> ... but nobody has implemented that subtlety.<br>
&lt;keithamus> iank_: that is long sailed<br>
&lt;keithamus> ... means you invalidate a bunch of engine optimisations<br>
&lt;keithamus> fantasai: but if we think people will want unsafe align for CBs not in viewport we could do that<br>
&lt;Rossen4> ack fantasai<br>
&lt;keithamus> ... probably a good starting point<br>
&lt;fantasai> s/probably/but this is probably/<br>
&lt;keithamus> iank_: The problem with that is you'll need some way to expose magical default for those cases<br>
&lt;keithamus> ... if we go down that path you'll need some magic alignment like overflow alignment<br>
&lt;keithamus> ... I'm fine with this proposal but I suspect we might... people might be reaching for unsafe more.<br>
&lt;keithamus> ... we should be cognizant that we might need to recommend it a lot more.<br>
&lt;keithamus> Rossen4: any other opinions?<br>
&lt;keithamus> PROPOSED: Accept proposal in 10316 but don't change normal behaviour when not using inset-area<br>
&lt;keithamus> s/PROPOSED/fantasai: PROPOSED:/<br>
&lt;keithamus> RESOLVED: Accept proposal in 10316 but don't change normal behavior when not using inset-area<br>
&lt;TabAtkins> So with this, I think Bikeshed's dfn panel behavior is just `inset-area: bottom span-right;` and *nothing else*<br>
</details>


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


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

Received on Wednesday, 29 May 2024 16:52:16 UTC