[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.

[bramus]

I see. Thanks for clarifying. Confirms that my guess, was merely a guess :)

[css-meeting-bot]

The CSS Working Group just discussed [web-animations-2] Prefer phase based start / end delays over converting time based delays, and agreed to the following:

• RESOLVED: Times in a non-time-based timeline are converted to their relative %s.
• RESOLVED: Once group effects are added, also add %-based delays/durations.

The full IRC log of that discussion

<TabAtkins> flackr: We defined a Web Anim 2 feature for converting time-based to run on non time-based timelines
<TabAtkins> flackr: So they'd "just work", continuing to use %s
<TabAtkins> flackr: Another idea came up to simplify, treating time-based durations and delays as their initial value (as if they're invalid)
<TabAtkins> flackr: This works for simple cases, but concern if you have a time-based group or sequence effect, the delays between effects are very important for relative timing
<TabAtkins> flackr: You couldn't take one of those and switch it to a different timeline if we didn't preserve those delays
<TabAtkins> flackr: So two options, one is continue to convert all times to relative %s when running a time anim on a non-time timeline
<TabAtkins> flackr: This ensures relative timing between effects stays
<TabAtkins> flackr: Other is we use initial values, but allow specifying %-based durations/delays, which let you define the relation of different effects in a non-time-based way
<TabAtkins> flackr: I think first is simpler, and what we already agreed on, but wanted to confirm.
<TabAtkins> TabAtkins: [missed]
<emeyer> TabAtkins: Locking ourselves into non-time-based is a weird syntax; if that’s not the case, fine
<emeyer> s/is/with/
<TabAtkins> flackr: We'll still want to define a % delay for these non-time things, but this wouldn't be required for existing ones
<TabAtkins> flackr: Something raised is it should be possible to take a time-based anim and switch it to a non-time timeline, and have it pick up where it left off
<TabAtkins> flackr: Which #1 will do
<TabAtkins> fantasai: So is proposed resolution that we'll autoconvert time-based delays, and *also* add % delays?
<TabAtkins> flackr: that sounds good to me
<TabAtkins> flackr: Group and sequence effects aren't implemented currently, so I think we should add % delays at some point before/as we implement group/sequences.
<TabAtkins> fantasai: If the main thing you'r eusing the delay for is to create overlapping effects, in a time-based system are you able to specify you anims in a way that's easy and comfortable, given you're combining %s and times
<TabAtkins> fantasai: Feels like that can be a little awkward, two different units
<TabAtkins> flackr: I think the way author would use %s is they'd define a duration for the overall group or sequence, adn the effects within would be %-based
<TabAtkins> flackr: They could mix-and-match but it would get confusing.
<TabAtkins> fantasai: Tangential, do we want to introduce frs as a keyframe offset mechanism? Then you don't have to reshuffle all your %s if you insert some frames.
<TabAtkins> (probably good to bring up as a separate issue)
<TabAtkins> astearns: Should raise separately
<TabAtkins> fantasai: Will do, just wanted to think aobut it in context
<TabAtkins> astearns: Othe ropinions? Rob, can you summarize resolution?
<TabAtkins> flackr: When running an animation with defined times in a non-time-based timeline, we convert those times to their relative %s of the overall effect.
<TabAtkins> +1
<TabAtkins> astearns: Concerns? Objectinos?
<TabAtkins> RESOLVED: Times in a non-time-based timeline are converted to their relative %s.
<TabAtkins> flackr: Should we also resolve to add %-based delays?
<TabAtkins> fantasai: If that's only needed for groups/seqs, we should add it when we do those.
<fantasai> fantasai: but we should resolve now
<TabAtkins> astearns: So proposed resolution is to add % delays once we add group effects?
<TabAtkins> (clearly just use `-duration: 100s`, then 5s == 5%)
<fantasai> fantasai: because having time-based delays that get auto-converted to lengths be the only way to sequence group affects on a scroll animation is just too weird
<TabAtkins> flackr: I'm good with that proposed res
<TabAtkins> astearns: Objections?
<TabAtkins> RESOLVED: Once group effects are added, also add %-based delays/durations.

[flackr]

Verified the spec already has the necessary conversions and has a note for future percentage support.