[csswg-drafts] [css-anchor-1][css-position] Add the “centering” behavior which is now defined as an example in the specs as something built-in (#8979)

kizu has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-1][css-position] Add the “centering” behavior which is now defined as an example in the specs as something built-in ==
The example in the specs that describes using math functions for the anchors involves a rather complicated calculation:

https://drafts.csswg.org/css-anchor-position-1/#example-a7ac0832

```CSS
  --center: anchor(--x 50%);
  --half-distance: min(
    abs(0% - var(--center)),
    abs(100% - var(--center))
  );
  left: calc(var(--center) - var(--half-distance));
  right: calc(var(--center) - var(--half-distance));
```

All of this to attempt to align the element and the anchor alongside their centers, and the example in the specs is not even enough: for a good result we need to add an extra element inside and use flex alignment:

https://codepen.io/kizu/pen/wvYYLGr?editors=1100


To quote @o-t-w from [the OpenUI discord](https://discord.com/channels/714891843556606052/961979349639245854/1119320647441584159), 

> This will be a common use case so its a shame that the solution given in the spec using abs() is so hyper-verbose.

I previously attempted to do this on a single element with `margin: auto`, but this did not give a good result as it lead to negative margins in some cases. Similar to if we would use `translateX(-50%)`, a single element solution won't work well with the fallbacks as well.

This is one of the very very common things developers do, and usually end up having to add wrappers to use flex/grid alignment, use margins (which can become negative), or transform (which creates subpixel rendering issues).

I think it is time to add something that would enable these use cases to CSS, either as a part of anchor positioning, or a part of the `css-position` spec in general.

Some ideas:

1. When talking about anchor positioning — if we could improve on the method described in the specs regarding the calculation — what if we could provide this behavior in some way as a built-in one, with some keywords or something? I don't like this option, as I couldn't produce a good result on a single element.
2. Allow using the dimensions of the element itself _somehow_ when anchoring. From what I understand, the main issue with allowing this is due to this: https://codepen.io/kizu/pen/abRRdNW — the dimensions of an elements can depend on its position when the width is auto (https://www.w3.org/TR/css-position-3/#abspos-auto-size). So, what if allow using something like `anchor-size(self width)` only when the width is not auto? this way, setting `width: max-content;` would unlock the self-anchor-size, allowing doing calculations for centering much much easier. I think I would prefer this solution, unless there are other limitations not related to the auto-sizing.
3. Similar how we have inset properties that align the element relative to one or more of its sides, what if we could have something like a `inset-center` or something, to align the element based on its center? In this case we'd need to update how the auto-sizing would work (probably disable it?), and how it would interplay with the `start` and `end` if they're set. Probably use them as “limits”, so if we'd say something like `inset-inline-center: 100px` alongside with `inset-inline-start: 0px`, then we would try to position the element so its center would be at the 100px coordinate, but if its `start` would go beyond the `0px` mark, we stop it at it. Overall, I like this option, but it seems to be much more complicated and would require more spec work than option 2.
4. Something else?

Overall, it is nice that we _can kinda_ align things with math functions, but, given this is a very common case, it would be really nice to have something build-in that would help the developers.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8979 using your GitHub account


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

Received on Friday, 16 June 2023 18:22:07 UTC