[css-anchor-position][css-position] Fixing the animation problem

[tabatkins]

Edit: This comment's proposal is out of data, our current proposal is over here.

Issue: Because the inset properties are four separate properties, you can't animate them "together" - instead you can animate each of the four independently, and hope that what you're expressing is reasonable for that to work. That's not always true!

For example, going from bottom: anchor(top); to top: anchor(bottom); (with the opposite inset being auto) will not animate properly - it'll be trying to interpolate top from auto to anchor(bottom) (which won't work), and similar for bottom. You can explicitly write a top/bottom: 0; in each case, which will technically animate, but not in a useful way; now, to get things to line up correctly, you'll need to specify align-self too:

.first {
  top: 0;
  bottom: anchor(top);
  align-self: end;
}
.second {
  top: anchor(bottom);
  bottom: 0;
  align-self: start;
}

...and align-self doesn't have animation rules to smoothly animate from start to end (yet, #9556). (And even if we did, it wouldn't work quite correctly - an align-self: start 50%; will center in an IMCB with a top of (0% + anchor(bottom))/2 and a bottom of (0% + anchor(top))/2, and that is very likely not halfway between its starting and ending position. In general, this sort of "interpolate a position within an interpolating range" doesn't produce a linear interpolation of the position in an absolute context; it produces a quadratic spline path instead.)

---

So that's the issue. How do we solve it? Here's my suggestion:

1. Repurpose inset-area. In addition to the existing grid-based syntax, add a [ <side-keyword> <length-percentage> ]{1,4} production, which similarly defines a rectangle and causes auto insets (and normal self-alignment) to resolve accordingly. So inset-area: top anchor(bottom);, for example.
2. Change the inset-area rules so that, rather than resolving auto insets (and normal self-alignments) at computed-value time, they resolve at used-value time. This removes the ability to animate the inset properties directly from the inset-area value.
3. Instead, make inset-area directly animateable. Add inset-area-mix(...), which represents the interpolated result between two inset-area values. This represents whatever insets and alignments would be required to make the position of the element interpolate smoothly between the two endpoints (rather than being a naive interpolation of edges and alignment). So long as all your actual inset properties and self-alignment properties are set to auto/normal, it'll Just Work.

I still need to give a little more thought to how the new side-based production handles alignment. In the grid syntax I can pretend that the default anchor is inside the containing block, so all the grid lines are correctly ordered and I can infer some positioning, but that's more difficult when the edges can indeed be misordered due to positioning. I'm pretty sure there's a good solution here, I just haven't fully worked thru it yet.

[tabatkins]

Talking this over with @fantasai, she pointed out that this will create very weird and confusing ergonomics for developers using positioning. So we suggest to rejigger it a bit.

Issues with above proposal:

• doesn't let you animate from a position specfied with inset-area to one specified with inset properties
• doesn't let you cascade the various positioning bits separately like you can do today (you'd be forced to indirect thru custom props)
• creates a confusing duplication with the existing inset and alignment properties

So instead of messing with inset-area, the new proposal is to use a new, fairly magical, property

• provisionally called position-animation
• captures all the relevant data to resolve the element's margin box position (as described above)
• authors can only specify split or combo, initial value split (for back-compat)
• split gives today's behavior, where insets and alignment properties all animate independently. When animating between split and any other value, the interpolated value is split.
• combo magically resolves at computed-value time to a package of all the relevant data (a "position package"). The used value of a "position package" is the size and position of the element's margin box, after resolving insets/alignment.
• getComputedStyle serializes split as split, and any other computed value as combo.
  (This way we don't need to expose syntax or serialization of position packages, they're internal to the UA.)
• There exists a computed-value representation for interpolating two "position package", so that we can represent intermediary states. The used value of the interpolation of two "position packages" is the interpolated position of each margin edge of the box. (This effectively requires the used-value layout information of both packages.) Thus, if both sides are a "position package", the element's actual position animates smoothly between the endpoints.

So, authors can write:

.foo { 
    position: absolute; 
    position-animation: combo; 
    transition: position-animation 1s; 
}
.foo.start { 
    top: 0;
    bottom: anchor(top);
    align-self: bottom;
}
.foo.end {
    top: anchor(bottom);
    bottom: 0;
    align-self: end;
}

...and when they swap the classes from .start to .end, it will smoothy animate the element's position, rather than doing a weird unintuitive animation, or not animating at all.

Using this, we can animate all of the following cases:

• top: auto to top: <length>
• inset-area: <anything> to inset-area: <anything>
• top/left/bottom/right to inset-area
• anchor(--foo top) when the element with anchor-name: --foo; changes
• (maybe?) top: 0 when the element establishing the abspos containing block changes (if we want to include abspos containing block resolution info in the package)

~fantasai and Tab

P.S. If this property is combo, and you animate any of the package component properties in a given keyframe, that keyframe will interpolate the missing properties and re-calculate the entire positioning package for that keyframe.

[andruud]

None of the issues listed with the first approach strike me as huge problems, whereas the "position package" proposal introduces a likely problematic layout dependency (the "magic"), and intermediate values that can't be represented. I'm not sure that's a net win as far as "issues" go, and I'm also not sure if this can be reasonably implemented, but it's an interesting direction to explore regardless. Especially if it could solve the anchor change case.

I'm confused by the model as stated, however. We seem to want to do layout of the box ignoring the "position package" (to determine what goes into the package), but then also it's really the position package that has the final say for the size/position?

provisionally called position-animation

I see the "provisionally", but I'd avoid anything related to "animation" in the property name. The animated aspect of this should come from the act of animating/transitioning the thing, not as an intrinsic part of the property.

split or combo

I don't think we actually need to have two values. Any interpolated state (that's not at the endpoints) can automatically behave as "combo".

getComputedStyle serializes split as split, and any other computed value as combo.
(This way we don't need to expose syntax or serialization of position packages, they're internal to the UA.)

It feels so wrong. :-) Would this be the first thing we can't even represent with Typed OM?

[tabatkins]

None of the issues listed with the first approach strike me as huge problems

I think they are pretty reasonable usability issues. Nothing technically wrong with what's in the first post, but it's not a great layering.

a likely problematic layout dependency

The second proposal is exactly identical in terms of power and layout dependency as the first. It allows literally no new abilities, save that it can interact directly with top/left/etc rather than requiring them to be packed into an inset-area value.

Literally, this was intended to be absolutely nothing but a movement of syntax; rather than blessing inset-area as "the way to get good position animation" and relying on inset:auto to not override that (which then requires us to recreate top/left/etc in inset-area, so we can actually do the things those properties are good at), we just move the "good position animation" thing to a third property, so we can continue to use top/left/etc as normal and still have it interact with inset-area as necessary. If you're reading anything else into this, that's just a failure on our part to communicate it well.

I don't think we actually need to have two values. Any interpolated state (that's not at the endpoints) can automatically behave as "combo".

No, we have to have split because people can animate the inset properties today and get the existing not-particularly-great behavior. And if they got this by specifying transition-property: all, then that would apply to the new prop as well, and change their behavior.

[andruud]

Literally, this was intended to be absolutely nothing but a movement of syntax;

Ah, OK. That's not how I read it. But I think I get it now, thanks. Instead of the author explicitly creating the "position package" via inset-area (v2), it's sort of automatically created from the existing inset properties and other stuff known at computed-value time.

However, it does go slightly beyond moving the syntax around if it solves the named anchor change issue. :-)

No, we have to have split [...]

Right, transition:all. I always forget about that.

[lilles]

Maybe I should have been able to infer from the discussion above, but what happens if you animate an inset property at the same time as animating the position package?: transition-property: top, position-animation

Just does not interpolate top separately if position-animation is combo?

[tabatkins]

However, it does go slightly beyond moving the syntax around if it solves the named anchor change issue.

Well, sure, but as we discussed internally, the named anchor change issue should end up being fixed anyway, with proper definition and reference to the machinery driving cq transitions.

what happens if you animate an inset property at the same time as animating the position package

I'm open to whatever behavior in that case. We could snapshot, or live-update, whatever's more reasonable for impls. There's no user argument for one behavior or another.

[kizu]

As a curious sidenote: when I was playing with “polyfilling” the position-area using the existing anchor positioning, I did stumble upon several transition issues, mostly related to aligning the popover close to the target based on the side it is shown.

The way I solved it in my case was by having two elements, and having transitions for a) inset properties (which were never auto), and the grid columns and rows (as a way to handle the “auto” aligning).

Here is this experiment: https://codepen.io/kizu/pen/zYMmVJd

(this comment is mostly as “as an author I did encounter this issue, would be happy with any solution, and for some cases we might have some workarounds already, though not ideal ones”).

[tabatkins]

Okay, further discussion with Anders and Rune led to some more evolution in this idea. They pointed out that the “inset-area affects inset:auto values” thing can't actually be done at computed-value time, like I hoped, because it relies on the writing mode of the containing block, and the containing block tree isn't built until later. So inset-area can't turn into animatable computed values anyway.

But, now that we're entertaining the “just make a magic way to animate good” solution, we don't actually need inset-area to be itself animatable in the first place. We can return inset-area to modifying the containing block itself, like in Apple's earlier draft, and still retain the animatability we wanted. This means that the inset properties would now compose with inset-area, rather than being an alternative to it.

So @fantasai and I have an expanded Round 3 of the proposal:

1. inset-area just changes the containing block, and inset properties then inset from that modified block (as proposed by Apple in July)
   • This is a better separation of functionality.
   • Allows for more powerful offsetting than margins do (because margin %s are always relative to inline avaiable space, while inset %s are relative to their own axis).
   • Lets us fix overconstrained cases when the anchor starts outside of the CB in a more deliberate way (rather than just relying on the 'top'/'bottom' /etc biasing rules). The CB shrinks to zero width/height and stays attached to the anchor, regardless of which side the anchor is off.
   • Also addresses some of the “absolute positioning, but in reference to the element I specify, not the nearest positioned ancestor” use case.
   • Composes with Grid's ability to set the CB to a grid area: Grid goes first, then inset-area modifies the CB further.
2. auto insets always compute to 0 when inset-area is non-none.
3. normal alignment adjusts based on the inset-area (per axis):
   • If the inset-area is center, or all three tracks: normal alignment resolves to anchor-center
   • Otherwise: normal aligns towards the “missing” areas.
   • Examples: inset-area: top / all; would align as align-self: end; justify-self: anchor-center;, while inset-area: top / left center; would instead use justify-self: end;/
4. “Good” interpolation is done by a separate property (provisionally called 'position-animation') that represents the used position, see positioning package method, above.