Re: [csswg-drafts] [web-animations-1,2] Iteration delay, animation-pause, effects group and effects sequence (#4459)

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()`.

GitHub Notification of comment by birtles
Please view or discuss this issue at using your GitHub account

Received on Monday, 28 October 2019 22:55:59 UTC