W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

Re: [csswg-drafts] [css-animations] Resolving dependencies in keyframes (#5125)

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Fri, 12 Jun 2020 08:43:49 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-643152879-1591951428-sysbot+gh@w3.org>
> I was thinking interpolation happens in specified value space, e.g. interpolation from `10em` to `20em` becomes `15em` at t=0.5, and then the `em` is resolved. Sounds like your mental model is that both `10em` and `20em` endpoints are dynamically resolved, and then interpolation happens on those values in `px`. I guess there's no observable difference.

At a spec level, we only define interpolation between computed values so we have to convert the endpoints before interpolating.

> > getComputedKeyframes()
> 
> Isn't that basically what this is? 🙂

Yes, I was thinking about having a `getKeyframes()` / `getComputedKeyframes()` pair like we have for timing values and then for CSS animations we could have `getKeyframes()` return an empty list to represent the fact that we can't faithfully represent the specified values while having `getComputedKeyframes()` produce a computed equivalent so you can still inspect and manipulate the animation.

However, I think that ship has sailed. We already have a `computedOffset` member in the result from `getKeyframes()` and we're already shipping `getKeyframes()` as returning something non-empty in at least Firefox and Safari.

> (@birtles: please review and confirm the examples).
> 
> * `em` units resolve dynamically against the computed value of `font-size`:
> 
> ```
> @keyframes test1 {
>   from { font-size: 10px; width: 10em; }
>   to { font-size: 20px; width: 20em; }
> }
> div {
>   animation: test1 10s -5s linear paused;
> }
> ```
> 
> At `t=0.5`, the computed value of `font-size` is `15px`. Hence the computed endpoints of the `width` interpolation are `[150px, 300px]`, and the computed value of `width` is therefore `150px + (300px - 150px) * t = 225px`.

Yes, that's right. There is an ordering dependency there. I believe @alancutter worked on this in the context of custom properties in Blink and said it was quite hard.

Those other examples all match my understanding of the expected behavior.

> What I think we should do now:
> 
>     * Spec the G-β behavior more clearly (I can try).

Thank you! 🤩

>     * Spec that the UA must behave as if computed keyframes are produced dynamically immediately before interpolation.

Sounds good.

>     * Spec that specified values are retained internally, but `getKeyframes()` outputs the computed keyframes. (There's a lot of confusion about "when" keyframes are computed at the moment).

Yes, that's right. Obviously this is in the context of CSS animations where the keyframes have not been overridden by script. For script-generated Web Animations or `CSSAnimation` objects where we call `setKeyframes()` we return any specified values from `getKeyframes()`.

>     * Add WPTs for difficult cases (I can contribute), reviewed by @birtles. Or investigate if they already exist.

Yes, that would be very helpful. I expect Firefox will fail a lot of them because we haven't implemented the ordering dependencies or registered custom properties.

> When it comes to `getKeyframes()`, is there still any open issue re. "ambiguous clobbering" of properties?

I'm not aware of any.

Thank you!

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5125#issuecomment-643152879 using your GitHub account
Received on Friday, 12 June 2020 08:43:51 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:27 UTC