Re: [css-animations] new property suggestion: animation-iteration-delay

On May 24, 2011, at 9:33 AM, Sylvain Galineau wrote:

> 
> [Chris Marrin:]
>> On May 23, 2011, at 8:40 PM, Sylvain Galineau wrote:
>> 
>>> 
>>> 
>>>> 
>>>> I would prefer to write the animation this way:
>>>> 
>>>> @-webkit-animation 'showhide' {
>>>> 	0%,100% {opacity: 0;}
>>>> 	5%, 95% {opacity: 1;}
>>>> }
>>>> 
>>>> .showElement {
>>>> 	animation-name: 'showhide';
>>>> 	animation-duration: 2s;
>>>> 	animation-iteration-count: infinite;
>>>>       animation-iteration-delay: 8s; }
>>>> 
>>>> -Estelle
>>>> http://standardista.com
>>> 
>>> +1. The ability to set a delay between iterations is important. The
>>> +alternative
>>> involves :
>>> 1) Updating the animation time to include delays
>>> 2) Create a new keyframe to represent the delay
>>> 3) Recalculate the % of the remaining keyframes.
>>> 
>>> This should be built in. One shouldn't need a spreadsheet or script to
>>> handle this simple scenario.
>> 
>> - Should the delay be before the iteration is complete or after
>> (determines when the event fires)?
> 
> After an iteration is complete. 
> 
>> - Should the iteration delay be in addition to the initial delay or
>> instead?
> 
> In addition to. The initial delay happens once. The iteration delay should
> happen after each iteration. (that is my expectation; curious about Estelle's)

yes, you understood me correctly. The animation delay is before the initial animation. The animation-iteration-delay is between each iteration after the completeion of the first (and maybe in the future can make use of calc() or attr() to make it more of a function.

> 
>> - If you're alternating, should the delay be before both the forward and
>> reverse cycle or just the forward?
> 
> Between each animation cycle/iteration regardless of its direction.

exactly
> 
>> - Why not a delay between each keyframe?
> 
> That could be a great way to achieve slow-mo effects. And very helpful for testing.
A good idea, but doesn't solve the animation-iteration-delay issue.

> 
>> You can see this quickly becomes too complex. 
> 
> Sure, it complicates things. Where does it get 'too' complex ?
> 
>> The initial delay is there to deal with the most common case of delaying 
>> the start of an animation so you can, for instance, control a sequence of 
>> events, like the build up of a page. 
> 
> And I find this very useful. Even though the use-case is different I don't
> think a one-off delay before the first iteration is sufficient.
> 
>> Everything else can (and should) be done as keyframes. I don't see
>> your 3 alternative steps as being very difficult. 
> 
> I'm positive that is easy for you. For average authors, this is far more 
> painful without authoring tools or libraries.

This keeps the animation in the CSS, without the use of javascript.

> 
>> A delay before, after or between keyframes is just part of the keyframe 
>> animation itself. 
> 
> That's how it has to be done today and not only does it requires extra 
> keyframes, adjusting/tuning the delay requires recalculating the percentage 
> for each keyframe in the animation. This is not something anyone wants to
> do by hand on a regular basis. 
> 
>> Adding a single new property wouldn't cover enough cases and adding the 
>> properties for all possible functionality would be too complex.
> 
> The former is a broad assertion. The latter may be true but simply assumes 
> the former.
> 
>> I don't think we should add this property.

I (obviously) don't think this property should be dismissed off-hand
> 
>> -----
>> ~Chris
>> cmarrin@apple.com

Here is a current animation and the suggested way to implement an animation-iteration-delay. I've implemented a longhand version, but expect that it would be part of the shorthand:

i've used the animation at http://standardista.com/sandbox/2d3d.html to explain this, since i had to change all the timing when adding an element to the animation.

	#side1 	{animation: 'rotation' 20s infinite;}
	#side2 	{animation: 'rotation' 20s infinite 5s;}
	#side3 	{animation: 'rotation' 20s infinite 10s;}
	#side4 	{animation: 'rotation' 20s infinite 15s;}
		
		@keyframes 'rotation' {
			0% {
				-transform: translate(0,0) rotateX(-90deg);
				transform-origin:bottom;
			}
			5% {
				transform: translate(0,90px) rotateX(0deg);
				transform-origin:bottom;
			}
			25% {
				transform: translate(0,90px) rotateX(0deg);
				transform-origin:top;
			}
			30%, 100% {
				transform: translate(0,180px) rotateX(90deg);
				transform-origin:top;
			}
		}

#shell p {-webkit-animation: 'showhide' 20s infinite;}

		#side1  p {-webkit-animation-delay: 0s;
		
		#side2  p {-webkit-animation-delay: 5s;}
		
		#side3  p {-webkit-animation-delay: 10s;}
		
		#side4  p {-webkit-animation-delay: 15s;}
		
@-webkit-keyframes 'showhide' {
				0%{-webkit-transform: translateX(-728px);}
				4%, 16% {-webkit-transform: translateX(0);}
				20%, 100% {-webkit-transform: translateX(728px);}
			}
 
		The above keyframe timing is great if you have 4 divs rotating in. 
		But, what if it changes to 3 or 5? You have to change the keyframe and the delays. 
		If we had animation-iteration-delay, we wouldn't have to recalculate the timing of the keyframes.
		The current method is to either extend the animation, or use animationEnd to remove class, and setTimeout to put the class back on.
		This way it could all be done in CSS.
		 
		My proposed syntax is:
		
		#side1 	{
			animation: 'rotation' 5s infinite;
			animation-iteration-delay: 20s;
		}
		#side2 	{
			animation: 'rotation' 5s infinite 5s;
			animation-iteration-delay: 20s;
		}
		#side3 		{
			animation: 'rotation' 5s infinite 10s;
			animation-iteration-delay: 20s;
		}
		#side4 	{
			animation: 'rotation' 5s infinite 15s;
			animation-iteration-delay: 20s;
		}
		
		@keyframes 'rotation' {
			0% {
				transform: translate(0,0) rotateX(-90deg);
				transform-origin:bottom;
			}
			15% {
				transform: translate(0,90px) rotateX(0deg);
				transform-origin:bottom;
			}
			85% {
				transform: translate(0,90px) rotateX(0deg);
				transform-origin:top;
			}
			100% {
				transform: translate(0,180px) rotateX(90deg);
				transform-origin:top;
			}
		}

		#shell p {
				-webkit-animation: 'showhide' 4s infinite;
				-webkit-animation-iteration-delay: 20s;
		}
		#side1 p	{
			-webkit-animation-delay: .5s;
		}
		#side2 	p{
			-webkit-animation-delay: 5.5s;
		}
		#side3 	p	{
			-webkit-animation-delay: 10.5s;
		}
		#side4 p	{
			-webkit-animation-delay: 15.5s;
		}

		@-webkit-keyframes 'showhide' {
				0%, 100% {opacity: 0;}
				20%, 80% { opacity: 1;}
			}

		*/
		</style>
		
	
    
    <div id="shell">
	<div id="side1"><p>papayawhip</p></div>
        <div id="side2"><p>indianred</p></div>
        <div id="side3"><p>slateblue</p></div>
        <div id="side4"><p>darkseagreen</p></div> 
 <!-- <div id="side5"><p>side5</p></div>
         <div id="side6"><p>side6</p></div> -->
    </div>

I posted the animation at http://standardista.com/sandbox/2d3d.html

if we uncomment a 5th and 6th elment, adding them to the main animation, all of the keyframe timings have to be rewitten. 

In this scenario, the animation in each of the divs is very, very simple. Additional sub-animations would lead to insanely complex animation keyframing calculations. Animations in children add throw animation js events thru bubbling. 


With the addition of animation-iteration-delay, to add additional elements would require simple changes in the animation delay and animation-iteration-delay values.

Using times instead of percents as was suggested  in a separate email as an alternative change to the spec would require the changing of the keyframe times as well... which would work in this case, but not in the case of randomly timed snowflakes. Adding time as selectors instead of percents makes animations less robust and therefore less reuseable.

-Estelle
http://www.standardista.com

Received on Tuesday, 31 May 2011 07:23:20 UTC