Re: [csswg-drafts] [css-anchor-position] Resolution of percentages: area or track? (#10314)

To go into a little more detail about the problem I see, currently you can write `left: 20%; right: 20%;` and, modulo some box-sizing details, be assured that the element's width will effectively be `width: 60%` and it'll be centered in the containing block.  This is simple and straightforward, and works the same as with other sizing pairs, like `margin-left: 20%; margin-right: 20%;`.

The behavior suggested in the OP would break that. left/width/right %s that sum to 100% would no longer fill the containing block, using the same values on both sides wouldn't center the element, and the properties overall would no longer act like margin-left/width/margin-right. (And a bunch of other pairs/trios across CSS.) It would be unpredictable what % sizes resolve to, since they'll depend on a different property (`inset-area`).

Worse, this would have an effect even when the user doesn't *meaningfully* use inset-area. `inset-area: span-all span-all` is *almost* equivalent to `inset-area: none` (it gives the same containing block size, but does trigger `anchor-center` alignment in both axises), but it would *also* have this confusing effect on left/right percentages, where they suddenly become relative to the left/right track sizes rather than the containing block's full size.

(`span-all span-all` isn't a very realistic value, of course, but `bottom` is (aka `bottom span-all`), and I don't think that `bottom` meaningfully indicates that the author cares specifically about the left/right tracks such that they'd want `left: 20%`/etc to resolve differently.)

----------

As an example of how I'd prefer to solve these use-cases (if we determine they need solving), additional anchor-size keywords could refer to the inset-area tracks - width/height already give the size of the "center" tracks, and we could have `anchor-size(inset-area-right)`/etc give you the width of the right track. Then you can do the same math as needed, just multiply it by 0-1.

This is more verbose, but it's also very clear and unambiguous. `left: calc(anchor-size(width) * .5)` and `right: calc(anchor-size(inset-area-right) * .5)`, while longer, are super clear in what they're doing, and make it immediately recognizable that you're trying to do some left/right alignment relative to some of the anchor concepts, rather than working like normal %s do. There is no implication that the element will be centered in the containing block, either (which is good, because it won't be, unless you just got lucky with the sizes).

This'll also allow even more stuff to be calculated off of, like `anchor-size(inset-area-span-right)` would give you the combined width of the right and center tracks. I have no idea if that's useful, but if *one* track has meaningful use-cases, I wouldn't discount the possibility that two do, too.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10314#issuecomment-2113314898 using your GitHub account


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

Received on Wednesday, 15 May 2024 19:31:35 UTC