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).
* 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.

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 "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".)
* 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).

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


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

Received on Tuesday, 13 May 2025 20:11:14 UTC