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

On Oct 16, 2014, at 3:37 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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.)

Oh, interesting. Since animation-duration defines the length of one iteration I thought it'd just shorten future iterations. But we really ought to recompute the active duration of the whole thing.

> 
>> - 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).

Yes.

> 
>> - 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.)

That was unclear to me, yes. So all properties are animatable - as in, they either interpolate following a timing function or switch values half way through that timing function - except for animation-* as those are effectively ignored inside @keyframes?

I'm fine with that, though I definitely missed it or somehow forgot about it. I didn't see it skimming through the Sophia minutes. Do you have a link to minutes or emails for this part?

(All css-animations props are marked non-animatable but we really use that propdef line to define interpolability, not whether it can be used in a keyframe rule)

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

Again, fine by me but would love to confirm this is everyone's understanding.

> 
> ~TJ

Received on Thursday, 16 October 2014 23:58:56 UTC