Skip to content

[scroll-animations-1] animation-range vs animation-duration #8405

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

Closed
fantasai opened this issue Feb 6, 2023 · 6 comments
Closed

[scroll-animations-1] animation-range vs animation-duration #8405

fantasai opened this issue Feb 6, 2023 · 6 comments

Comments

@fantasai
Copy link
Collaborator

fantasai commented Feb 6, 2023

If animation-range-start, animation-range-end, and animation-duration are all set, and duration doesn't exactly match the available range, what do we do?

Options proposed so far:

  • Ignore animation-range-end.
  • Ignore animation-duration.
  • Take the smaller duration.

Related question: if animation-duration and animation-range-end are given but not animation-range-start, do we:

  • define the range as the normal timeline start through the specified range end? (pins the duration at the start of the timeline)
  • scope the animation to the given duration, pin it to the specified animation-range-end, and calculate the used value of animation-range-start accordingly?

Fwiw, my original interpretation was that the animation-range properties each (independently) cut the timeline down to a particular segment, and then duration and delay play within that segment instead of within the whole timeline.

An alternative view would be that animation-range is similar to inset, delay to padding or margin, and duration to width, and they operate as a set at the same time.

Which worldview do we want to go with? (Or something else?)

@flackr
Copy link
Contributor

flackr commented Feb 17, 2023

I would prefer if all three values are not their initial auto or normal values that we ignore the animation-duration. My rationale here is that it will be common for both animation-range-start and animation-range-end to be defined together, sometimes as a single keyword (e.g. animation-range: entry), and so it makes sense to me that this takes precedent over the declared duration given that it is overconstrained.

Using the shorter of duration and animation-range-end - animation-range-start works reasonably if the range is shorter than the duration, but when the range is longer than the duration the animation will no longer align to the range-end which feels awkward as well.

@flackr
Copy link
Contributor

flackr commented Feb 17, 2023

Fwiw, my original interpretation was that the animation-range properties each (independently) cut the timeline down to a particular segment, and then duration and delay play within that segment instead of within the whole timeline.

An alternative view would be that animation-range is similar to inset, delay to padding or margin, and duration to width, and they operate as a set at the same time.

The nice thing about thinking of animation range in this alternative view is that it is effectively css keywords for specifying the animation start time and end time - whereas the former is a new concept.

@flackr flackr added the Agenda+ label Mar 2, 2023
@fantasai
Copy link
Collaborator Author

fantasai commented Mar 11, 2023

Thinking about this more while working on the iteration count edits, I think the model we should go with is:

  • The animation is attached to a timeline. But more specifically, it is attached to a timeline attachment range. By default this is the entire timeline, which in the case of a scroll-driven timeline is finite, and in the case of a time-driven timeline is infinite. The attachment range is the portion of the timeline that the animation is laid out in (somewhat analogous to a containing block).
  • The start/end of this attachment range can be controlled with animation-range.
  • Any resizable aspects of the animation will stretch or squish to fit the attachment range (like flex items inside a flex container). So if the duration is flexible (auto), then we fill the whole range. If the duration is inflexible, then we pin the animation to its start point.
  • Delays are like margins. They don't change the attachment range, but they reduce the amount of space available for the “content” and shift it accordingly. The initial value of a delay is auto, which functions like 0 except when there's additional constraints; this allows pinning to the end of the attachment range by specifying an end delay.
  • If there's an iteration count, we repeat that many times within the “available space” in the attachment range (reduced by any delays). If the duration is flexible, it is reduced to fit (like multi-col column widths given a column-count). If the duration is inflexible, additional iterations may overflow the attachment range. However...
  • While animation frames outside the attachment range are used for interpolation, they are not part of the active interval of the animation. The animation ends at the end of the attachment range (similar to how content outside a scroll container impacts layout but is not visible).

CC @flackr @birtles

@flackr
Copy link
Contributor

flackr commented Mar 20, 2023

@fantasai that is my working model as well (I thought it was the model we had already TBH 😄 ) and would be consistent with the proposed resolution of animation-range "winning" if all three are specified. I agree with all of the points.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [scroll-animations-1] animation-range vs animation-duration, and agreed to the following:

  • RESOLVED: Accept proposal in the issue
The full IRC log of that discussion <emilio> flackr: when you specify all of animation-range-start/end/duration
<emilio> ... it's not possible to satisfy all of these constraints
<fantasai> Proposal -> https://github.com//issues/8405#issuecomment-1464810166
<emilio> flackr: where we've arrived is that animation-range is setting the absolute points at which an animation starts and ends and all other constraints are applied inside that range
<emilio> ... so your duration could make the animation shorter but a longer one would be clipped to that range
<emilio> ... this is my mental model as well
<emilio> fantasai: [goes over comment]
<flackr> q+
<Rossen_> ack fantasai
<Rossen_> ack flackr
<emilio> flackr: one point of clarification: for time-based timelines you need the range to start at the point you tell them to play
<emilio> fantasai: if you set a negative delay you might end up with a start before the document timeline start
<emilio> ... if you have an animation range that could be negative range, but you're not going to see that animation
<emilio> flackr: if you specified animation-range-start: 0s that implies the time at which the document loaded
<emilio> ... so the auto start range would be the point at which you play the animation
<emilio> fantasai: I see, so when we add times to animation-range it makes the model consistent
<emilio> YehonatanDaniv: so if duration is shorter than start-end which one takes precedence?
<emilio> fantasai: so if it's smaller it might clip the animation, but if the duration is larger the animation ends until the end of the range
<emilio> YehonatanDaniv: but if I force iterations to 1...
<emilio> fantasai: if you have no delay, you layout the keyframes along the duration, but if the end of the range is before, any frames after get ignored
<emilio> YehonatanDaniv: ok
<emilio> YehonatanDaniv: so start/end either define my duration if auto or a clipping range
<emilio> fantasai: yeah
<emilio> PROPOSAL: [fantasai's comment ;)]
<emilio> RESOLVED: Accept proposal in the issue

@fantasai
Copy link
Collaborator Author

animation-range "winning" if all three are specified

(I would have interpreted that as the range end shortening the duration, not clipping the animation, so I thought they're different.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants