New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[scroll-animations-1] Interaction with 'animation-iteration-count' #8233
Comments
My initial thought was "ignore", but authors may want to create repeating effects which is otherwise very cumbersome with spreading repeats over the Keyframes set.
Also, in case of repeats there may be an interaction with |
Passing on to @kevers-google - I heard him talk about this before, so pretty sure he has this one figured out already. |
The experimental implementation in Blink currently factors in animation-iteration-count when determining the intrinsic-iteration-duration. Since effect end is 100% and equal to start delay + end delay + iteration count * iteration duration, we can calculate a duration that makes the end time match up when using duration auto. Similarly if specifying a time-based iteration duration we can compute the end time and then scale/normalize accordingly to make it align to 100%. This normalization is useful for example if setting the animation timeline to convert a time-based to a scroll-based animation. The infinite iteration count implies that iteration-duration is zero. At present, the spec handles 0 duration * infinite count by resolving the product to be zero (https://www.w3.org/TR/web-animations-1/#calculating-the-active-duration). Though using infinite iterations with a scroll-linked animation is not particularly useful, we can at least define sensible behavior. In this case, the animation collapses to zero active duration. |
+1 to what @kevers-google, we have implemented (and spec'd in web-animations-2 intrinsic iteration duration) to split the length between iterations.
From a pure API point of view, I would expect these keyframes to work similarly to how they behave when they are outside of the However, animations don't create extra sets of keyframes for each iteration so having the keyframes be different for each iteration is not something that easily maps to animations. I would propose that we take a naive position and either ignore these keyframes or calculate their progress assuming a single iteration even though it will no longer map correctly after the range is split between iterations. My preference would be for the latter as I think it would be the closest to honoring what the dev asked for. E.g. if your animation-range is enter, and your keyframes are |
The CSS Working Group just discussed
The full IRC log of that discussion<argyle> astearns: who takes this one?<argyle> kevin ellis: could outline what's in chrome see if that makes sense <argyle> kevin ellis: for scroll linked, the duration is 100% so we can workk backwards form auto. starting from 100%, remove start and end delay, take that result divided by iteration count, to get the itnrinsic iteration duration <argyle> kevin ellis: this is consistent with time values rather than percentages, working out the effect end time is, then normalizing to match that to 100% <argyle> kevin ellis: this makes it easy to switch from scroll linked and time based animations <argyle> kevin ellis: int he case of time based, you're working forward to calc the effect end, for scrollbased you're working backwards from end target 100% to the iteration duration needs to be for everything to line up <argyle> flackr: this is also paving the way for the web animations 2 proposals for sequence effect to and group effect for those to infer their duration <argyle> astearns: any questions about blink's current implementation? <argyle> astearns: this address your issue fantasai ? <argyle> fantasai: i think so yeah <argyle> flackr: we also have to decide wwhat to do about keyframes that have defined they're at a particular point of the timeline <argyle> fantasai: yeah, other half of the issue <argyle> flackr: my proposal was that we work out their relative proportions and then those proportions repeat. they'll no longer line up with what they declared, b ut many cases this will lmatch author intent <argyle> flackr: if you have 2 iterations during enter, it'll repeat that 2 times during the entry phase <argyle> fantasai: you assume an interaction count of 1, attach all the frames. that creates something that you scale down when you apply the iteraction count. <argyle> fantasai: ok <argyle> flackr: ok <argyle> fantasai: i liek that, it kinda makes sense <argyle> astearns: alright, i think this is beyond my ability to summarize <argyle> astearns: what is the proposed resolution? <argyle> fantasai: we have 2 right? <argyle> fantasai: first, we do apply iteraction count and we divide the duration by the iteration count <fantasai> -> https://github.com//issues/8233#issuecomment-1375890456 <argyle> kevin ellis: dividing the active interval by the iteraction count to get the intrinsic iteration duration <argyle> astearns: that's the first resolution? <argyle> astearns: any objections? <argyle> astearns: leave it up to editors to spec terms of theyre just ways to express the resolution <argyle> astearns: resolved on that <fantasai> -> https://www.w3.org/TR/web-animations-1/#the-active-interval <argyle> RESOLVED: divide the active interval by the iteration count to get the intrinsic iteration duration <argyle> astearns: what else? <argyle> flackr: 2nd was, we resolve the named keyframe offsets against the active interval and they will be repeated in these subsequent iterations <argyle> RESOLVED: assume an interaction count of 1, attach all the frames. that creates something that you scale down when you apply the iteraction count. <argyle> astearns: anything else on this? <argyle> astearns: i imagine as you specify this out, there will be a few little details that can be editor discression or we can resolve later <argyle> astearns: next issue! |
We don't define what happens if the animation-iteration-count is not 1. We could:
infinite
as1
, and loop over the keyframes for each iterationIn the latter case, things get weird if keyframes are attached using named range offsets. We could...
CC @bramus
The text was updated successfully, but these errors were encountered: