Re: [css-animations] Proposal for handling changes to animation-* properties while an animation is running

On Thu, Oct 16, 2014 at 2:26 PM, Sylvain Galineau <galineau@adobe.com> wrote:
> On Sep 9, 2014, at 9:08 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Sep 9, 2014 at 9:04 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> Here's the proposal: just let everything be adjustable.  The start
>>> time of the animation (when the animation starts applying; when value
>>> is adjusted (in the animation-* properties, or in the @keyframes
>>> rule), just recompute what value the animation would be at if it had
>>> always had those values, and start applying that instead.
>>
>> This paragraph is nonsense.  I meant to say:
>>
>> Here's the proposal: just let everything be adjustable. The start time
>> of the animation (when the animation starts applying) is kept stable;
>> when any value is adjusted (in the animation-* properties, or in the
>> @keyframes rule), just recompute what value the animation would be at
>> if it had always had those values, and start applying that instead.
>>
>
> I took a first simple stab at stating this like so:
>
>         # Changing the values of animation properties while the animation
>         # is running has no effect on the amount of time that has elapsed since the
>         # animation started running i.e. once the animation is running, updates to
>         # 'animation-delay' have no effect. The remainder of the animation runs
>         # according to the new animation property values.
>
> I'd like to dig a bit deeper though; assuming we're half-way through the 2nd cycle of a 3-iterations animation of 2s duration i.e. we're at t=3s:

Okay, so we currently have:

animation-duration: 2s;
animation-iteration-count: 3;
animation-direction: normal
animation-timing-function: i dunno, let's say "ease"

The animation started at t=0s, we're currently at t=3s

what happens when the following property/value is applied?
>
> - animation-duration: 1s. Iteration #2 ends; iteration #3 starts and lasts 1s.

No, this changes the entire animation to last 3s, so the animation
immediately ends (dispatching an animation-end event, but no iteration
events). (Assuming that iteration events dont' fire at the end of an
animation, which I'm not going to verify right now.)

> - animation-iteration-count: 1. This sets us past the animation's active duration. animation-end fires, forward-fill is applied i.e. we're done. (Same thing would happen if the animation didn't iterate and we set its duration to a value smaller than the time elapsed thus far)

Yes.

> - animation-direction: alternate. The second half of iteration #2 reverses.

It runs in reverse, yes.  More specifically, it immediately jumps to
50% of the reversed progress and then proceeds in reverse.  (This is
identical for this case, because all timing functions cross their own
reversal at 50% time, but if we were any other time into the
iteration, it would cause a jump).

> - animation-timing-function: <anything other than what's currently running>. Rest of animation follows new timing function.

Yes, and, as above, it immediately jumps to the progress corresponding
to the time% of the new progress function; if it switched from "ease"
to "linear" that's about a 10% jump in progress.

> Then we get to what happens when these property updates are made using keyframe rules e.g.:
>
>         @keyframes time-is-relative {
>                 from {...}
>                 50% { animation-duration: 1s; }
>                 to { ...}
>         }
>
>         #foo { animation: time-is-relative 3s; }
>
> I assume the answers we want here are the same as before i.e. the rest of the animation complies with the new animation properties. In this case, the animation ends itself after running for 1.5s because start/elapse time do not change and we're past the new duration.

animation-* properties are not animatable.  Even in the "all
properties are animatable" world, animation-* properties aren't
animatable.  (If this was unclear at any point in the talk about this
feature, it's definitely the intent.)

> The oddest one (imo) is a keyframe rule updating the animation property (or animation-name):
>
>         @keyframes self-absorbed {
>                 from {...}
>                 50% { animation: self-absorbed 2s; }
>                 to { ...}
>         }
>
>         #foo { animation: self-absorbed 3s; }
>
> What should happen here is less clear to me from an author intent perspective. In this particular case I'd think self-absorbed runs for 1.5s, then restarts, runs for 1 second, restarts, runs for 1 second...etc.

Not possible either.

~TJ

Received on Thursday, 16 October 2014 22:38:31 UTC