- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Oct 2019 22:55:58 +0000
- To: public-css-archive@w3.org
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 https://github.com/w3c/csswg-drafts/issues/4459#issuecomment-547181193 using your GitHub account
Received on Monday, 28 October 2019 22:55:59 UTC