[css-anchor-position-1] Behavior with transforms and offset-path

[kizu]

Disclaimer and additional links

I'm submitting my feedback following my experiments with the current implementation of anchor positioning in Chrome Canary.

I wrote an article about my experiments, but decided to fill most of my feedback as separate issues here.

A quick summary of related links:

• anchor positioning specs
• my article with the experiments

Right now, the positions for the anchors do not take into account things like transforms, offset-path (position: sticky, which is covered by #8448).

In practice, there were cases in my experiments where I wanted to use those — transforms and offset-path for the animations/transitions (see the animations for the “four quadrants” in my article — I want to attach things that move, but because transforms or offset-paths are not used, I have to animate things via top and left).

Currently, specs do not mention any of these cases — if those are intended to not be supported, the specs should be clarified, but I would suggest looking into providing an option to somehow follow those.

I understand that for the transforms and offset-path things are probably much more complicated — but I foresee a lot of cases where developers would want an option to follow those. I wonder if this could be something like anchor-transform or whatever, which could be optionally used with transform on the anchored element? And maybe something similar with offset-path (though, maybe it could be similar to position: sticky in that it is easier to describe how it could work by default?)

[xiaochengh]

It should definitely work with position: sticky, but we haven't done the spec work yet: #8448

Would you mind splitting this bug by moving the stickypos related stuff to #8448 and leaving the remaining here?

[tabatkins]

Not taking transforms into account (including offset transforms) is intentional - nothing else does, either, because they're strongly post-layout, purely visual effects (and disrupt the notion of elements having a "left side"/etc, outside of their local transform context).

[kizu]

(copied with modifications from the OpenUI discord)

I thought about a case where we'd want to follow the transform of the target's container: https://codepen.io/kizu/pen/WNLYRvx

Basically, what if we want to attach a popover to a button inside a rotated, or otherwise transformed container?

Here is what we get right now in this example (in Canary with experimental platform features flag due to anchor positioning), when the element is outside of the rotated container (inside the rotated one things are obviously ok), or when it is yoinked into the topmost layer via popover API:

This can also be a case for when someone implements a sliding side-panel, with sliding animated via a transform, but then what if the panel would contain a defaultOpen popover that should be attached to some element via anchor positioning? With the way things work now, that element would exist completely outside of the transformed space, and to replicate what we want to achieve, we'd have to do a lot of work by manually transforming the popover.

For regular abspos, we could argue, that the idea was that we now could place the popover near the element, so we would expect the behavior as in the third container in the codepen:

But then, when we have a Popover API — the element is reparented to the topmost layer, thus loses that transformation context.

Should we be able to either somehow follow a transformation of a selected element, or be able to disable putting the element in the topmost layer (which, I imagine, can be problematic on its own?), or something else?

[xiaochengh]

It seems doable to me if we want to additionally apply additional transforms to the anchored element after layout. There are some issues with the transform origin, but they may be fixable.

The issue is that it won't work well with position fallback, because it's post-layout. And I don't see any way to make position fallback work with general transforms.

[kizu]

I think it might be reasonable to lose the ability to apply fallbacks when following the transforms. Though, I wonder if this is something that might benefit from a property/keyword somewhere that controls this? Could there be cases where there'd be a transform which we don't want to follow? Something like “neutral” transforms, like the initial state ones (scale(1), translateZ(0) etc) come to mind, where an element could have it, but the developers would not want this to interrupt the fallback mechanism.

[xiaochengh]

Could there be cases where there'd be a transform which we don't want to follow?

I think this might be the common case. If the style doesn't explicitly have a transform, then there shouldn't be any transform.

Exceptions might only be cases similar to <selectlist>, which look broken if the popover doesn't follow the transform by default.

[bfgeek]

Right - we don't want to allow a layout dependency on transforms unfortunately. Lots of things are accelerated for users, and this would force a bunch of things onto a slow path.

[yisibl]

There doesn't seem to be any discussion of offset-path here, do I need to open a separate issue?

Test in Chrome 127:
https://codepen.io/yisi/pen/eYaJopE

anchor+offset-path.mp4

---

Chrome bugs: https://issues.chromium.org/issues/341875179

[jonrimmer]

Many web apps with a "canvas" UI use transforms as a key part of their rendering. I.e. translate() to handle panning and scale() to handle zooming. Anything built using react-flow for example. Adding tooltips, popovers and context menus on canvas items is an common requirement for these apps, but if I read this correctly, it will be impossible to use anchor positioning for these kinds of use-cases? If so, that seems like a big gap.

[jonrimmer]

It's perhaps also worth nothing that the most popular JS library for achieving anchored positioning, Floating UI (the successor to Popper.js), does take CSS transforms into account, so as it stands anchor-positioning will not be adequate to replace it.