[css-anchor-position-1] Should animations use View Transitions as their backing mechanism? (by default or as an opt-in)

[FremyCompany]

At today's presentation (F2F Mountain View 2024), Tab proposed some "magical" computed-time animation for the anchored-element when its position or size would otherwise change as a result of anchoring updates.

As far as I understand, this would be implemented as an internal position-coordinates property which would be the bounding box of the element, would be set by the anchor positioning choices, and would be animatable.

One issue with this is that this animation requires layout at every step of the animation, and there is no guarantee that the intermediate layouts are even valid.

For example (see figure below), if your popup switches from a "top center" tooltip (above the anchor, sized as a wide but not tall box) to a "left center" tooltip (on the left of the anchor, sized as a tall but not wide box), then you can end up with an intermediate "mid-wide, mid-tall" box that does not fit its content, so it overflows, and authors have little to no control over this.

An alternative design would be to instead trigger scoped view transitions. Doing this would take a screenshot of the initial state (or multiple small screenshots if there are multiple parts in the animation) and each part is then transitioned using the view-transition pipeline, which has various affordances to deal with these details. This also allows to animate different parts in different ways, especially if the content of a wide popup and a tall popup is different (some elements might move, appear, disappear, etc...).

I would posit that this is easier to implement than the position-coordinates animation magic, and is more efficient.... pending the view-transition animations are already implemented (which is not yet the case in all browser).

[FremyCompany]

Proxying @tabatkins's reply that was not otherwise minuted:

1. Sounds interesting.
2. We did not consider this because it didn't exist at the time we started.
3. Existing JS libraries obviously don't do this, and are getting used, so maybe not required.

(if I understood all points correctly)

[bramus]

View Transitions won’t cut it here, as VTs are animating snapshots instead of the actual element.

Because of that, the text will not nicely reflow as the tooltip gets moved. The change in aspect-ratio is also troublesome. See https://codepen.io/bramus/pen/abMPEdY?editors=1010 that has an implementation that uses View Transitions. Recording below:

anchor-transition-using-view-transitions.mp4

[bramus]

In case you are wondering: using the regular fade-in/fade-out VTs offer you, also doesn’t cut it: https://codepen.io/bramus/pen/VwRqQYL

anchor-transition-using-view-transitions-2.mp4

[FremyCompany]

Great examples, thanks @bramus!

I can see how the result isn't great in those cases indeed, and would look better with a reflow+relayout at every frame.

There might still be cases where you don't want to do this for performance reasons, but I agree that this would require work, and not work great by default, at least with the current defaults.

I'm still worried that a layout transition could also result in poor results, though. Nothing says that the text would fit the intermediate size, and it would keep juggling between lines, so it would be pretty unreadable.

Another desgin that probably works fine is to fade in and fade out the final states without transition between them. Then you do not need to support intermediate designs that do not make a lot of sense, you just fade out the old version, and fade-in the new version. In many cases, that is probably sufficient?

[bramus]

Another desgin that probably works fine is to fade in and fade out the final states without transition between them. Then you do not need to support intermediate designs that do not make a lot of sense, you just fade out the old version, and fade-in the new version. In many cases, that is probably sufficient?

Don’t remember who exactly I was talking to about this, but we came to the same conclusion: might be OK to simply fade out the element at the old position, move it behind the scenes, and fade it in at the new position.

This behavior could potentially be a new keyword for the position-animation property, in addition to the (still tentatively named) magic.