W3C home > Mailing lists > Public > www-style@w3.org > October 2014

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

From: Sylvain Galineau <galineau@adobe.com>
Date: Thu, 16 Oct 2014 21:26:04 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: "<www-style@w3.org>" <www-style@w3.org>
Message-ID: <5CB87619-A2A8-4920-84BC-DC998686D88A@adobe.com>

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: what happens when the following property/value is applied?

- animation-duration: 1s. Iteration #2 ends; iteration #3 starts and lasts 1s.
- 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)
- animation-direction: alternate. The second half of iteration #2 reverses.
- animation-timing-function: <anything other than what's currently running>. Rest of animation follows new timing function.

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. 

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. 
Received on Thursday, 16 October 2014 21:26:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:47 UTC