[web-animations-2] Iteration delay

[verbessern]

Greetings to everyone,
I'm curious about the relation of the property discussed in "Proposal for animation-pause property" at https://lists.w3.org/Archives/Public/www-style/2016May/0080.html and its relation to the web animations specification 2 - group of effects and sequence of effects. It seems to me that instead of using groups of effects, its better to have the discussed property and to allow one animation to have more then one effect instead of the one 'target effect'. It does not look nice, to have to define two animations with the same attributes, when there are two effects, at least because of the redundancy. When a group is need, then simply the required effects will be connected to the animation. The sequence of effects could be made by delaying each effect accordingly, hard codding its value, or attaching it to the onfinish event of the previous effect. This could simplify the design of many common animation cases.

[birtles]

I appreciate the desire to keep things simple but after digging into this (and based on experience with SVG/SMIL too), I think the chaining approach ends up being more complicated.

As that issue points out, there are a number of open questions with iteration delays:

• What fill mode do you apply, if any, between iterations?
• If you use an animation direction of 'alternate', does it change?
• At what point does the iteration count increase? Before or after the delay?
• etc.

Because the answers to these questions are not obvious, whatever behavior is specified is going to confuse some authors whereas the grouping approach makes the behavior explicit.

Furthermore groups allow:

• Nesting so whole sequences can be iterated
• Timing effects to be applied across a complex scene (e.g. apply step timing function to the whole animation)
• Re-using timing parameters by specifying them on a parent group.

Groups are also more easily mapped to markup allowing CSS authors to access this behavior too rather than having to tie together onfinish event handlers with JS.

Groups also enable further optimizations by user agents that are able to send the entire group to a separate process/thread and play it smoothly without the potential jank introduced by having to execute JS when each animation ends.

So I think groups are the preferred approach here but authors are still obviously able to chain animations together using JS by either hard-coding delays or using onfinish handlers. They can also still share timing information by re-using the property bags used by getTiming()/updateTiming().

[verbessern]

My infinite respect to the awesome work done around this and the other standards. However, I believe, that the stated questions should be answered, and the feature included. Only from a logical perspective, if there is a start delay, an end delay, there are iterations, there should be "in between iterations delay". And is it complex?... well I don't think that all of this is simple, its all complex by its nature. And using additional objects to simulate it will move the complexity to the use cases, instead to the specification. So its one more drop into the ocean:

• for the first one, there should be a separate fill property (iteration-fill = ...). Happily at least this will not trigger the need of an infinite memory, as it is with the fill mode of the effects, because the iteration-fill will not be having an effect out of the "active interval".
• the "alternate" animation direction is the time change, that is not related to the fill mode, but if such a relation has to be explicitly defined, then yes, the "in between iteration delay" will be available and in "alternate" direction, for a consistency, and it will be defined relative to the "normal" direction always, because "alternate" is only changing the "time" of the effect, not the effect itself, that is just executed in reverse, but still, the same effect.
• the "iteration count" could be defined as "the currently active iteration index" then there will be no need to clarify is the time between iterations part of the previous or the next iteration. By this definition it will be not explicitly defined to be part of any iteration, and the iteration count will be incremented before the next iteration starts (...well, its not really "incremented" per se, its calculated from the time).

So from all of the questions remains only the fill mode, that could be included.

For the groups, yes, such a feature is needed, but not for the purpose of simulating a more simple behavior.

[verbessern]

ps. I will open another issue related to the groups, not to mix here.

[birtles]

I've updated the issue title to reflect what I understand to be the core proposal here.

I personally don't think the essential complexity it adds to the model is warranted and am concerned it has a poor upgrade path for authors. (That is, while it helps with some simple cases, as soon as you want to anything more complex, you need to drop the iteration delays and represent them using groups.)

However, I'm happy to leave the issue here for now in case others are interested in pursuing it. It is out of scope for level 1, however.

[verbessern]

I think that the animation authors, will mostly create simple animations (work with single effects, not with the time line inheritance), and will benefit from the feature. And for the upgrade path, I think that the specifications must embrace the "proper way to do it" not the "current way to do it", which are not always the same. When a group of developers, regardless how skilled and with good intentions, missed in some code base some feature, or created improper one, that must not affect the whole world for years to come. The effort needed to upgrading some existing code base, is far less, then the effort put into the code bases that will be created subsequently to reflect the standard plus the uncountable use cases that will be developed. To the question "Is that feature useful?", I vote "yes", because its existence reflects the logic in my previous comment.

[bramus]

@birtles What if animation-iteration-delay accepted two <time> values, e.g. animation-iteration-delay: 0s 2s.

The first value would be a before delay, the second value a after delay. The before delay would fill like backwards, the after delay like forwards.

If authors want to fill the backwards, they’d do something like animation-iteration-delay: 2s 0s. If they want to fill forwards, they’d do animation-iteration-delay: 0s 2s. The defined values only apply in between iterations, not when the animation starts.

The property could be a shorthand for animation-iteration-delay-before and animation-iteration-delay-after (names to be bikeshed).

The iteration count increases in between the two values: after animation-iteration-delay-after has passed and before animation-iteration-delay-before starts.

EDIT: While this can stretch out the effect on either side, it does not give the option to define a delay with no fill mode …hmm
🤔

[birtles]

@bramus Thanks for following up on this. As you noted in your update, even just getting the filling part right is difficult.

I still think the best thing we can do for everyone is to push ahead with timing groups. They cover this use case in an intuitive and extensible way without further complicating the model, and so many other use cases too. After that, I think we could add syntactic sugar for some version of iteration delay if it proved necessary.

Timing groups are already outlined in Web Animations level 2. The most useful next step would be to consider how they might be exposed to CSS.

[kizu]

I was looking if there is an existing issue, glad I found it. This is something that I needed a lot in my work.

This is also a rather commonly asked question, for example, on StackOverflow https://stackoverflow.com/questions/13887889/css-animation-delay-in-repeating, with 100+ upvotes.

Developers want this and have had to come up with cumbersome workarounds for years. Example article from 2016: https://css-tricks.com/css-keyframe-animation-delay-iterations/

[Netail]

Hello,
Recently came across a use case where I needed to add some delays between iterations, with which I ended up with some annoying workaround mentioned in @kizu's comment.

A property like animation-iteration-delay (to stay in line with animation-delay & animation-iteration-count) would be very very very useful. It would have the same specs as animation-delay, but this delay is used between the animation iterations instead of only before the animation starts. An alternative naming could be animation-iteration-interval?