Re: [css-animations] When/how are keyframe values computed?

On Fri, Aug 8, 2014 at 10:07 AM, Sylvain Galineau <galineau@adobe.com> wrote:
> This is a follow-up to a previous thread [1] and a recent telcon discussion [2] on this topic.
>
> We know css-animations interpolate the computed value of the properties being animated. We want to clarify how the animating values are computed when they depend on the value of another property. (We will cover the application of non-animatable properties separately)
>
> Using dbaron's telcon example:
>
> @keyframes A {
>    0% { font-size: 32px; width: 10em }
>    50% { width: 15em }
>    100% { font-size: 64px; width: 20em}
> }
>
> #elem { animation: A linear 5s; font-size: 16px }
>
> What value do we expect for the width property at 0%/0s, 50%/2.5s and 100%/5s ?
>
> Likewise, what happens if the font-size and width properties are animated separately?
>
> @keyframes B {
>    0% { font-size: 32px }
>  100% { font-size: 64px }
> }
>
> @keyframes C {
>    0% { width: 10em }
>   50% { width:15em }
>  100% { width: 20em}
> }
>
> #elem { animation: B linear 5s, C linear 10s; font-size: 16px }
>
> Though the discussion was somewhat confusing - on the phone, timelines are hard - I think we covered these three approaches:
>
> A. Properties in a keyframe rule do not influence each other i.e. the width property computes against the font-size: 16px set by the #element rule.
>
> font-size   0s     2.5s     5s
> A         32px     48px   64px
> B         32px     48px   64px
>
> width       0s     2.5s     5s     10s
> A        160px    240px  320px
> C        160px    200px  240px   320px
>
>
> B. Animating a property affects the computed value of all properties that depend on it. This doesn't change the interpolation of font-size but width now resolves against the animating font-size property:
>
> font-size   0s     2.5s     5s
> A         32px     48px   64px
> B         32px     48px   64px
>
> width       0s     2.5s     5s     10s
> A        320px    720px  1280px
> C        320px    640px   960px   320px
>
> (Note: C ends at 320px because B ends at 5s, does not fill forward thus C computes against font-size:16px after the 5s mark)
>
> C. Animated property values can resolve values against properties animated in the same @keyframes rule i.e. if font-size is animated and width is animated in EMS, the width animates against the interpolating font-size. If the font-size is animated by a separate animation, it is not 'seen' i.e. C will animation against font-size: 16px.
>
> font-size   0s     2.5s     5s
> A         32px     48px   64px
> B         32px     48px   64px
>
> width       0s     2.5s     5s     10s
> A        320px    720px  1280px
> C        160px    200px  240px   320px
>
>
> In this specific case, Gecko, WebKit and Blink follow C. Trident appears to do B.
>
> Feedback of which you think is best and why is helpful. Examples to explain why you think one approach is worse/better are encouraged.
>
> And of course, if I missed something or incorrectly represented an approach, do chime in.
>
> [1] http://lists.w3.org/Archives/Public/www-style/2014Jul/0297.html
> [2] http://lists.w3.org/Archives/Public/www-style/2014Jul/0617.html

If I'm understanding your notation correctly, I think option B is what
we should be aiming for.

In general, I think we should strive for CSS Animations to have the
same effect as just manually animating the same properties in JS;
anything else seems likely to be confusing, and I don't think there's
a decent a priori reason to do anything different (besides
implementation concerns, perhaps).  This means that all properties
should resolve against the "current value" of all other properties,
which includes animated things.

~TJ

Received on Friday, 8 August 2014 17:34:43 UTC