[web-animations-2] Prefer phase based start / end delays over converting time based delays

[flackr]

In web-animations-2 we defined a procedure for converting time based animations to non-time based timelines to allow switching the timeline of a regular animation to a progress-based timeline and have it "just work"

The conversion currently takes place if the iteration duration is not auto. I think the developer expectation would reasonably be that we only try to convert a time based animation if all of the fields are time based and that if any of them are not that we would force the time based fields to 0.

Filing this in relation to the handling in our implementation.

[flackr]

@kevers-google FYI

[flackr]

Since we now have animation-range for the attachment these non-time based timelines, I think it would be much simpler if we dropped all time-based values for their default values when applied to a non-time based timeline. The somewhat common case of assigning a non-time-based timeline on a time-based animation essentially fills the specified animation-range.

Applying this would mean removing the procedure for converting time based animations to non-time based timelines and instead using any time values as their initial values which would go down the "auto" duration path.

TLDR Proposal is:
Time based specified duration, start delay, and end delay will compute to their initial values ("auto", 0, 0) when applied to an animation using a non-time based timeline.

[flackr]

That said, dropping the specified time values means that we would lose the proportional sizes of start delay, end delay and duration in both single effects and in the future for sequence and group effects. Long term it would probably be better to allow developers to define durations / delays applicable to either timeline type by specifying their values in percentages (of the applied animation-range), but the question is do we want to have the complexity of continuing to convert time based values to their relative proportions in the meantime. @birtles Do you think it's valuable to try to convert values specified in one timelines units to another?

[birtles]

The main use case I'm aware of is having a scroll-based animation that switches to a time-based one and runs to completion once it passes a certain threshold (the "point of no return"). Whatever we do, I hope that's a relatively easy effect to achieve. I'm fine with deferring features provided we have a concrete proposal about how they will work in future so we don't paint ourselves into a corner.

[flackr]

Thanks! In order to make that use case just work I think it's better to stick with the direction we've gone right now where we convert time values to their relative percentages preserving the relative differences in duration / start / end delays.

This goes back to the original proposal at the top of the issue to just make sure we don't convert away non-time based delays (even though we currently don't support setting those - heh).

[flackr]

When I originally wrote this issue my concern was that a developer may have specified range-based start and end delays which could get clobbered, e.g.

<style>
.animation {
  animation: fade-out 1s;
}
.scroll-driven {
  animation-timeline: scroll();
  animation-delay: contain 0% contain 100%;
}
</style>
<div class="scroll-driven animation"></div>

Previously the procedure for converting time based animations to non-time based timelines would see the non-auto duration from .animation and determining that it was a time based animation "convert" the delays to 0. Since we have moved these timeline based delays to animation-range this is no longer an issue.

However, while discussing this with @kevers-google, he raised concerns about whether we wanted to keep the complexity of converting time based animations to proportional ones automatically. So in the spirit of evaluating this with the group, I wanted to revisit this with some concrete examples. I think at a high level there are two possible proposals which we'll consider with the following animation:

<style>
@keyframes fade-out {
  to { opacity: 0; }
}
.animation {
  animation: fade-out 1s 1s;
}
.scroll-driven {
  animation-timeline: scroll();
}
</style>
<div class="scroll-driven animation"></div>

Options:

1. Keep the procedure to convert a time-based animation to a proportional animation. The 1s start delay will be determined to be 50% of the overall time so we'll get a scroll animation which after 50% of the scroll range will start to fade out, e.g. animation-delay: 50%.
2. Treat time based durations and delays as their initial values (e.g. auto and 0 respectively). This means that by default the duration will fill the animation-range. The times will be completely ignored and the fade-out animation will fill the scroll range starting to fade out from the top of the scroller, e.g. animation-delay: 0

I'm not sure what the author would expect between the two options, however @birtles raises an interesting use case of switching an animation that is currently running based on scroll to continue to run based on time. If at some point in the developer removes the scroll-driven class, then we want the animation to continue to run from the point where it was. While either option can work for single animations (note: we'd have to modify the procedure to set the timeline to account for the changing delay), I think if we have group / sequence effects with various time based start/end delays and we want to preserve their progress that we have to go with option 1 so that their relative progress and timing can be preserved.

TLDR; I propose resolving on option 1: keep the procedure to convert a time-based animation to a proportional animation.

[bramus]

My assumption was that because time makes no sense for scroll timelines, the set times would be ignored (thus, using their initial values). But if that paints us into a corner as outlined above, let’s just keep it. The suggested option 1 also reflects the mental model @fantasai outlined here.

I do wonder how switching from scroll based to time based would go in practice though. If I were to take a guess, I would expect something like this to happen upon switching timelines of an animation:

• Calculate how far in the scroll-driven range we are, e.g. 25%
• Look at the duration set for the time-based version, e.g. 4s
• Run the remaining part of the animation (here 100% - 25% = 75%) for the remainder of the duration (here 4s * 75% = 3s) – This example assumes a linear easing to keep the maths simple.
• When there is an animation-delay set, it is ignored upon switching if the scroll-timeline was a progress greater than 0% because in that case it had already started.

[ydaniv]

Actually I tend to agree with @bramus' initial thought that resetting to initial is more expected. I also think that this conversion isn't necessary, reusing the effect is more important, and still possible, but with an extra line the author can declare a different animation and switch between the two. So prefer option 2.

Regarding the "point of no return" case, it seems to me that at that point the progress, and thus the effect, are precisely defined, so it should be easy to stich another time-based effect to that state. @birtles did I get your use-case correctly?

[birtles]

Regarding the "point of no return" case, it seems to me that at that point the progress, and thus the effect, are precisely defined, so it should be easy to stich another time-based effect to that state. @birtles did I get your use-case correctly?

Yes, I believe that's correct.

[flackr]

@bramus where this gets really inconsistent is when you have group effects. For example consider the SequenceEffect illustrated at https://www.w3.org/TR/web-animations-2/#the-start-time-of-children-of-a-sequence-effect

If we ignore their start delays you will get a very different composition of the effects when you switch from a Document timeline to a Scroll-driven one. I.e. it will just be A then B then C, rather than having the slight overlap (from the negative start delay) and delay.