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

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

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

> - Why not a delay between each keyframe?

That could be a great way to achieve slow-mo effects. And very helpful for testing.
 
> 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.

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

> -----
> ~Chris
> cmarrin@apple.com
> 
> 
> 
>

Received on Tuesday, 24 May 2011 16:33:42 UTC