Re: [csswg-drafts] [css-anchor-position-1] Behavior with transforms and offset-path (#8584)

> > Do we want to take an anchor's transforms into account, and how far would we like to go? Only honor those on the default anchor when at an anchor recalculation point? Or more? We don't want to allow transforms to affect layout, ever, I assume, not even as an opt-in? Because that means main-thread work, and no compositing.
> 
> Right, the potential for _layout_ effects is the obvious problem here.
> 
> So just to review how we handle scroll:
> 
> * at anchor recalculation points, we calculate all anchor references based on their actual scrolled position. (So `anchor()` resolves to the scroll-accurate offset, and you can get accurate results from `max(anchor(top), anchor(--foo top))`/etc.) This _is_ capable of changing the the size of the positioned element.
> * at all times, we track the default anchor's scroll offset, and when it differs from the remembered scroll offset from the last anchor recalculation point, we apply the difference as a translate to the positioned element. (So `anchor()`/etc do _not_ respond to this difference, and the `max()` example might no longer be correct, etc.) Since it's a transform, this is _not_ capable of changing the size of the positioned element; it just shifts it.
> 
> The live-responding transform is a little clumsy, since it can break constraints you write into your offsets. It's a reasonable compromise, tho, for the benefit of being able to "stick to" the default anchor reliably.
> 
> If we want transforms to work similarly, we need to adopt similar constraints.
> 
> * at anchor recalculation points, we calculate all anchors based on their actual _transformed_ position (using the axis-aligned 2d bounding box of the transformed anchor).

This one sounds like the bare minimum (and maybe enough?), pretty straight-forward to solve, and will be similar to how we already deal with scrolling, yes. No opt-in mechanism needed for this, as far as I can tell (we didn't add one when implementing this for scrolling although it was a behavior change).

> * at all times, we track the default anchor's transform. We need to track some _point_ on the default anchor (I'll discuss which point later) - when its position differs from its position at the last anchor recalculation point, we apply the difference as a translate.

So this is for a more broad support for transforms (not just at recalculation points), briefly mentioned in https://drafts.csswg.org/css-anchor-position-1/#determining-position

We don't have to solve or spec both these at the same time. Responding at anchor recalculation points will most likely cover most use cases. At the same time, it would be interesting to know how far we would like to go.

> Which point, tho? Translates don't really care which we use, but rotates and scales definitely do. And is the point on the anchor itself, or on its transform bounding box? I think the right answer is that it's a point on the bounding box. But which point? I think the "right" answer is going to depend on some other properties.
> 
> * We should have a property (`anchor-transform`?) that lets you specify this point explicitly, so you can do whatever you want.
> * Otherwise (if the property is `auto`), if the positioned element is using `position-area`, we can infer a reasonable point based on the area:
>   
>   * If the area has exactly one corner touching one of the anchor's corners, use that corner. (Numbering the area sections like a phone keypad, areas like "1" or "1245".)
>   * Otherwise, if the area has exactly one edge touching one of the anchor's sides in an axis, use the center of that side. (Areas like "2", "12", "123", "25", or "123456".) (It can either touch both sides in the other axis, like "25", or neither in the other axis, like "123".)
>   * Otherwise, use the center of the bounding box. (Areas like "5" or "123456789".)
>   * (Afaict, this will actually let you reproduce the "dots on the edge of a spinning box" video you posted.)

The big question here is if that's a use case we want to support at all. I just made it as an extreme example. Oh wait, I had left one thing out for "simplicity". Here's another one, with rectangles that get sized by a `position-area` that's affected by transforms.

Same as the previous example, plus this:
```html
<style>
  .box {
    position: absolute;
    position-anchor: --a;
    width: 100%;
    height: 100%;
    background: lightgray;
  }
</style>
<div class="box" style="position-area:top right;"></div>
<div class="box" style="position-area:top left;"></div>
<div class="box" style="position-area:bottom left;"></div>
<div class="box" style="position-area:bottom right;"></div>
```

https://github.com/user-attachments/assets/dcb85b5a-d37d-40da-a80f-7e9c2bda72a7

As long as we respond to transforms only at anchor recalculation points, that seems fine. My examples rely on more responsiveness than that. Although the last example is the only one that has boxes that get resized based on transform changes, it's not that different from the first example. The first example only changes the offsets of the anchored elements, but in our implementation at least, this means performing layout (nothing is resized, but their offsets in the layout fragment tree change - that's main thread stuff). Does this throw a spanner in your thought works?

> * Otherwise, use the center of the bounding box. (This will make it respond to translations, but _not_ the anchor rotating or scaling itself at all. That's intentional, since we can't guess at what part we're intending to anchor to.)
> 
> The unstated next question is whether it's possible to do this by default at this point, or if we need to continue ignoring transforms by default and key it to the property that controls what point we're tracking (like `anchor-transform: none` as the initial value, and `anchor-transform: auto`/etc would turn it on).

If we only respond at anchor recalculation points, I think we can do it by default. Then it's just like scrolling.

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


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

Received on Wednesday, 14 May 2025 08:38:34 UTC