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

On May 24, 2011, at 8:53 AM, Chris Marrin wrote:

> 
> 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)? 
The delay should start when animationEnds is fired.

> - Should the iteration delay be in addition to the initial delay or instead?

The initial delay is an initial delay. 
The iteration delay is an iteration delay. 
Their names explain their functions.
Lets use a "falling snow' example. you want each snowflake to start falling at a different time, and you don't want their to be an obvious repeating pattern, so you want them all to fall at different speeds and restart at different intervals. With the four timing functions:

duration
delay
timing-function
interation-delay

you can create such an effect

but snow is too simple of an example.... how many people make snow. But there are many examples where you animate something, and then need to wait a certain amount before animating it again. like a 2 sided banner: you see the front, the back, the front again, the back again, iterating infinitely
the front and back each have animations within them.
but you only want the contents to animate when they show... and you know they are not showing when flipped back. 

paused/play could work, but you're thinking of removing it from the spec PLUS requires behavior (javascript or user interaction like hover) to change state.

iteration-delay solves this issue.

literally, 50% or my repeating animations could use this feature.

> - If you're alternating, should the delay be before both the forward and reverse cycle or just the forward?

it's an iteration delay, so between each iteration

> - Why not a delay between each keyframe?

if you want to add that, go go it, or allow animations within keyframes. Plus, you can delay within a keyframe. I have that delay in my example above:


>>> 	5%, 95% {opacity: 1;}

there is a delay between 5% and 95%

> 
> You can see this quickly becomes too complex.

I think you're choosing to see it as too complex, but there is nothing complex about it.  
very similar to delay, but between iterations instead of at the start.



> 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. Everything else can (and should) be done as keyframes. I don't see your 3 alternative steps as being very difficult. A delay before, after or between keyframes is just part of the keyframe animation itself. Adding a single new property wouldn't cover enough cases and adding the properties for all possible functionality would be too complex.



The iteration should be fairly simple to code in js, except that webkitAnimationEnd does not always fire, and also gets the event from it's children, which is why after a few hundred CSS animation effects, i am in desperate need of being able to implement this with CSS instead of JS.

While you can create the effect with an animation, such as

0% {start}
0.35%{keyframe1}
0.42%{keyframe2}
0.78%{keyframe3}
0.93%{keyframe4}
1.02%{keyframe5}
1.35%{keyframe6}
1.42%{keyframe7}
1.78%{keyframe8}
1.93%{keyframe9}
2.02%{keyframe10}
2.35%, 100%{end}

while adding a long delay makes the keyframe measurement really complex, 
if you have different delays between different element animating, you can NOT reuse the above ridiculous animation, instead you have to create a completely separate animation rule.

That is what is complex, and why it is easier to control animations with JS instead of CSS. And, that is where the spec is failing. Animations should be controllable in CSS without adding so much weight to the css file that it becomes not manageable.

> 
> I don't think we should add this property.

I think we need to add this property.
> 
> -----
> ~Chris
> cmarrin@apple.com
> 
> 
> 
>

Received on Tuesday, 24 May 2011 18:35:35 UTC