Re: [csswg-drafts] [css-anchor-position][css-position] Fixing the animation problem (#9598)

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:

```css
.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

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


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

Received on Friday, 17 November 2023 23:24:41 UTC