[csswg-drafts] [css-anchor-position-1] Grid-based anchoring syntax? (#9145)

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

== [css-anchor-position-1] Grid-based anchoring syntax? ==
One of the major syntax distinctions between the current spec and the [grid-based proposal](https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/) was the grid-based syntax itself. At its core, it gave a way to specify a containing block for the positioned element in terms of a 3x3 grid, with lines set up relative to the containing block's edges and the anchor's edges.

Some of my teammates remarked that they did find expressing simple positions via the grid to be more intuitive; particularly, having to write things like `left: anchor(right);` can be a little difficult to parse if you're not already thinking in terms of the inset-modified containing block. (Which direction keyword is the positioned element vs the anchor, etc.)

If this mental model is worth accommodating, we can bake that into the current proposal pretty easily, via an alternative 'inset' shorthand:

```
Name: inset-area
Values: <the [grid syntax from the grid proposal](https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/#anchor-area%E2%91%A0)>
```

For example, the slides had one case that used `position-area: top / start center;` to position the element into row 1, column 1-2 - above the anchor element, aligned between the left edge of the containing block and the right edge of the anchor.

In the current spec you'd write that as `bottom: anchor(top); right: anchor(right);`; in this proposal you'd alternately be able to write `inset-area: top / start center;` and get the same effect.

Some open questions:

* In the example above, should `top` and `left` be `auto` or `0`? Probably makes sense to have them be `auto` if we go with #9125's idea; that way the default will push the positioned element flush with the anchor, which is probably what's intended, but allow the author to still get full alignment control if that's what they need.
* Should this just be an alternate syntax branch of `inset` itself, rather than a separate shorthand? I think it's completely grammatically distinct, but it probably removes any possibility that we could reserialize with the grid form. (That is, if you asked for the computed style of 'inset' in the above example, it would have to return `auto anchor(right) anchor(bottom) auto`, rather than `top / start center`.)
* What happens when the anchor element is partially or completely overflowing the abspos's containing block? I don't think this is answered in the Grid proposal. If we just ignore that and handle it naively I think we still get a good answer - it'll be aligned in the same way regardless, you just might have zero space in your inset-modified containing block for alignment values to work on.

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


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

Received on Wednesday, 2 August 2023 22:11:22 UTC