[scroll-animations-1] Interaction with 'animation-iteration-count'

[fantasai]

We don't define what happens if the animation-iteration-count is not 1. We could:

• ignore it entirely
• split the length of the timeline (or what remains after limiting by animation-range/delay) by the number of iterations, treating infinite as 1, and loop over the keyframes for each iteration

In the latter case, things get weird if keyframes are attached using named range offsets. We could...

• attach those frames, then ignore them while attaching any other frames using the iteration count
• attach those frames, then split the timeline up by those frames and iterate any other keyframes within each interval
• something else?

CC @bramus

[ydaniv]

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.
So I see 2 options:

1. split the length as you wrote above for finite numbers.
2. split automatically per a given duration in pixels, just like background-repeat, but then we'll need to also think of either a new syntax or interaction with animation-duration.

Also, in case of repeats there may be an interaction with animation-direction, as in alternate direction on repeat or not, and with animation-delay-end that needs to be considered.

[bramus]

Passing on to @kevers-google - I heard him talk about this before, so pretty sure he has this one figured out already.

[kevers-google]

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.

[flackr]

+1 to what @kevers-google, we have implemented (and spec'd in web-animations-2 intrinsic iteration duration) to split the length between iterations.

In the latter case, things get weird if keyframes are attached using named range offsets. We could...

attach those frames, then ignore them while attaching any other frames using the iteration count
attach those frames, then split the timeline up by those frames and iterate any other keyframes within each interval
something else?

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 animation-range, that being they produce a negative or positive offset within the effect.

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 enter 0% and enter 100%, having 2 iterations would result in the effect playing twice.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] Interaction with 'animation-iteration-count', and agreed to the following:

• RESOLVED: divide the active interval by the iteration count to get the intrinsic iteration duration
• RESOLVED: assume an interaction count of 1, attach all the frames. that creates something that you scale down when you apply the iteraction count.

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!