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

On 31/05/2011 5:22 PM, Estelle Weyl wrote:
>
> 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.


I'm now following what animation-iteration-delay does. The snowflake 
example was hard to visualize but that is because my visualization was 
like some kids drawing. I have never observed snow falling in my life. 
Using an example that someone from Australia may understand. Sometime 
when it begins to rain, you get a few drops first, then you may have 
some steps up in intensity before it begins to bucket down (Australian 
term for very heavy rain).

Here is a break down as I understand it:


animation-duration: 10s;
animation-iteration-count: 5;

|----------|----------|----------|----------|----------|


animation-duration: 10s;
animation-iteration-count: 5;
animation-delay: 8s;

|-------D--|-------D--|-------D--|-------D--|-------D--|


animation-duration: 10s;
animation-iteration-count: 5;
animation-delay: 8s;
animation-iteration-delay: 40s;

|----------|----------|----------|----------|-------D--|


For me, instead of multiplying 4 iterations of 10s, equaling 40s. It 
would be easier having a count of the cycles. I see 
animation-iteration-count and animation-iteration-delay being confused 
by authors and having them wonder how something like this works.

animation: 'rotation' 20s infinite 15s;


I presume the first value with seconds is for animation-iteration-delay. 
I think that using cycles would be more meaningful and a cycle can be 
expressed as a value followed by 'c'. Something like this.

animation: 'rotation' 4c infinite 15s;


I would be interested to be able to interweave animation-iteration-delay 
and having something that is not a time unit helps.



animation-duration: 10s;
animation-iteration-count: 5;
animation-delay: 8s
animation-iteration-delay: 1c

|----------|-------D--|----------|-------D--|----------|

                            or

|----------|-------D--|----------|----------|----------|


Is the later solved with animation-iteration-delay-count?


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


Bullet time. I already seeing it. Can you explain this further Sylvain.


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


This is interesting. Please see this new thread,

http://lists.w3.org/Archives/Public/www-style/2011Jun/0083.html

and this demo.

http://css-class.com/test/css/3/2d-animation/swap-via-script-roll-webkit.htm

I don't see this as really an issue of if JS script is required or not 
but that certain animations may work better with some of the control is 
in the JS and some of the control in the CSS (think jQuery). One major 
thing with the above demo is that the animation name is not in the CSS. 
Relating this back to animation-iteration-delay.

Look at the JS below and consider how this would work with animation?

document.getElementById('elem').style.animationIterationDelay = 'value';

Consider that this could be called in via JS.


Also, how would animation-iteration-delay work with animation-fill-mode?

http://dev.w3.org/csswg/css3-animations/#the-animation-fill-mode-property-


I myself am still learning what animation-fill-mode does. I have only 
figured how how to use this in an awkward manner.

animation-fill-mode: forwards;


>>> I don't think we should add this property.
>
> I (obviously) don't think this property should be dismissed off-hand


I like the property. I could make some interesting digital rain. I need 
to examined the rest of what Estelle had. It had me confused. I guess my 
animation uses and ideas does likewise.



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Friday, 3 June 2011 11:08:05 UTC