- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 May 2024 21:05:28 +0000
- To: public-css-archive@w3.org
Yes, this sizing behavior was very intentional, and necessary for reasonable behavior, even *if* it can result in a too-small containing block size sometimes. Note that sizing and alignment are strictly in that order - size first, then align. In every other alignment keyword, that's fine - if you size into the full containing block size (and don't overflow right away), you can then left, right, or center yourself and you'll *always* stay within the containing block. This isn't true for anchor-center - if you size into the full width of the containing block, and then center on the anchor, it's *very easy* to overflow the rect. Here’s an example. There are two solutions to this. The first is what the spec currently says - give it the sizing constraint that actually keeps it within the containing block rect when it's centered on the anchor. The second is to give it the full size, but then *un-align* it if necessary to keep it in the containing block rect. This is the "slide" behavior we've talked about, and intentionally deferred so it can get more design thought. (See #9960) We want sliding for more than just anchor-center (I mention wanting anchor-left and anchor-right - Bikeshed's own dfn panels use JS to get an "anchor-left" behavior with sliding.) When we design the sliding behavior more generally, it should override this containing block size reduction for anchor-center, and let you size as large as you want. But before then, it's better to be too small in some cases than overflow (possibly into the unscrollable area) in even more cases. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10315#issuecomment-2111141074 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 May 2024 21:05:29 UTC