[scroll-animations-1] separate animation-range and animation-delay #7901 #8219

fantasai · 2022-12-13T20:50:01Z

No description provided.

flackr · 2022-12-14T19:51:40Z

scroll-animations-1/Overview.bs

@@ -736,67 +736,79 @@ spec: cssom-view-1; type: dfn;

 	A set of animation keyframes can be attached
 	in reference to [=named timeline ranges=]
-	by adjusting the duration of the animation.
+	by restricting the to the specified timeline range.


nit: "the to the" I think is meant to be "them"?

Though this isn't quite correct. The keyframes can be whenever they want to be - but the animation start and end are restricted to the range. It is valid to make an animation with keyframes that are outside of the range, e.g.

@keyframes anim { cover 0% { opacity: 0; } contain 100% { opacity: 1; } } .target { animation: anim; animation-timeline: view(); animation-range: contain; }

This will result in an animation which when the element enters the contain phase starts at some percentage which depends on its size.

animation-range (further insetted by delay) is used to define the start and end of the active phase of the animation.

Ok, updated terminology. Let me know if I got it right yet. (I also inserted a diagram.)

flackr · 2022-12-14T21:03:04Z

scroll-animations-1/Overview.bs

+	are set within this restricted range.
+	If a duration ('animation-duration') is given,
+	it measures from the range-restricted start,
+	and further restricts the range-restricted end.


It is just used instead rather than replacing it, isn't it? E.g. similar to how width is just used instead of right for absolute positioning regardless of whether that further restricts or expands the width: https://jsbin.com/bekiceg/edit?html,css,output

I think it would make more sense to take the more restrictive one, since if you set a shorter animation-range-end and a longer duration, it'd seem weird to ignore the animation-range-end?

I'm confused by the interaction with duration here. Ranges relate to ViewTimeines, and these don't have a specified duration (unless we specify interaction with animation-iteration-count) but rather a duration of auto or 100%, right?
So unless there's some sort of animation-iteration-count: infinite/auto i'd expect animation-duration to be ignored and be calculated from ranges and delays.

@ydaniv That's another approach we could take: if animation-range-end has a valid non-normal value, ignore the duration. (It seemed the discussion in an earlier issue wanted them to both apply somehow.)

Yes, I thought that's the main use-case, so you're saying range-end could be normal and duration in <length> can determine the actual duration, staring from the range-start?
SGTM, I'd also prefer to respect the range-end and clamp to that

So taking the shorter of <range-end> - <range-start> and <duration> still isn't really honoring the request:

If the range is shorter, you're not using the specified duration

If the duration is shorter, the animation doesn't end at range-end.

If we don't need to follow the precedent for box positioning, I'd suggest that when a start and end range are both not normal we use that instead of the duration.

OK, I'll open a new issue about this. -> #8405

scroll-animations-1/Overview.bs

flackr · 2022-12-14T21:27:24Z

scroll-animations-1/Overview.bs

-	i.e. a ''2s'' delay effectively shortens the animation duration,
-	whereas ''-2s'' lengthens it.
+	Shifts the end of the animation
+	(i.e. when keyframes attached to 100% progress are mapped)


This is true if iteration count = 1 and end delay is 0, but if iteration count > 1 there will be multiple points at which 100% is reached and if end delay is > 0 100% will be reached before animation-range-end. This is the end time of the animation.

OK, I think I fixed this.

flackr · 2022-12-14T21:27:54Z

scroll-animations-1/Overview.bs

+	<dl dfn-for="animation-range-start, animation-range-end" dfn-type=value>
+		<dt><dfn>auto</dfn>
+		<dd>
+			The end of the animation attaches to the end of the animation duration.


Same comment as for range-start.

scroll-animations-1/Overview.bs

flackr

Sorry for the delay. I don't know why but this review doesn't show up in PR's awaiting my review (https://github.com/w3c/csswg-drafts/pulls?q=is%3Apr+is%3Aopen+user-review-requested%3A%40me) so i have to search for it every time.

Overall I think this is looking really close now and if you want to move my particular comments to followup issues that's fine with me.

flackr · 2023-02-02T20:18:27Z

scroll-animations-1/Overview.bs

+	are set within this restricted range.
+	If a duration ('animation-duration') is given,
+	it measures from the range-restricted start,
+	and further restricts the range-restricted end.


So taking the shorter of <range-end> - <range-start> and <duration> still isn't really honoring the request:

If the range is shorter, you're not using the specified duration

If the duration is shorter, the animation doesn't end at range-end.

If we don't need to follow the precedent for box positioning, I'd suggest that when a start and end range are both not normal we use that instead of the duration.

scroll-animations-1/Overview.bs

flackr · 2023-02-02T20:24:02Z

scroll-animations-1/Overview.bs

 		<dd>
-			Defines the delay as a duration. See [[CSS-ANIMATIONS-1]].
+			The start of the [=active phase=]
+			is determined as normal.


I prefer auto as it seems more in line with how implicitly computed defaults are specified elsewhere and aligns with animation-duration: auto.

I believe how we determine the start time of the animation should be updated in web-animations-2 3.3.7. Playing an animation to account for range start and end. This currently explains how the "normal" behavior gets a 0 start time for scroll driven animations and the current timeline time for time-based animations. The logic there should be updated to account for range start and range end and then the css-animations spec can refer to that procedure to play the animation.

I went with normal because (unlike duration) we aren't magically computing a range: if the range is not otherwise defined, the timeline range is the whole timeline, as normal.

Filed as #8406

…c#7901

fantasai requested a review from flackr December 13, 2022 20:50

flackr reviewed Dec 14, 2022

View reviewed changes

fantasai force-pushed the animation-range branch from daba5c9 to dc19c5c Compare December 15, 2022 20:11

ydaniv reviewed Dec 15, 2022

View reviewed changes

scroll-animations-1/Overview.bs Outdated Show resolved Hide resolved

fantasai force-pushed the animation-range branch 2 times, most recently from 1253065 to aa6b2f6 Compare December 15, 2022 21:14

ydaniv reviewed Dec 17, 2022

View reviewed changes

scroll-animations-1/Overview.bs Outdated Show resolved Hide resolved

fantasai force-pushed the animation-range branch from aa6b2f6 to 448fb60 Compare December 18, 2022 16:55

fantasai added the scroll-animations-1 Current Work label Jan 28, 2023

flackr approved these changes Feb 2, 2023

View reviewed changes

fantasai force-pushed the animation-range branch from 448fb60 to bf2f2a4 Compare February 6, 2023 22:09

[scroll-animations-1] separate animation-range and animation-delay w3…

fcf6f11

…c#7901

fantasai force-pushed the animation-range branch from bf2f2a4 to fcf6f11 Compare February 6, 2023 22:10

fantasai merged commit e6ca22a into w3c:main Feb 6, 2023

fantasai deleted the animation-range branch February 6, 2023 22:11

fantasai mentioned this pull request Mar 11, 2023

[scroll-animations-1] What's the point of animation-range? #7901

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[scroll-animations-1] separate animation-range and animation-delay #7901 #8219

[scroll-animations-1] separate animation-range and animation-delay #7901 #8219

fantasai commented Dec 13, 2022

flackr Dec 14, 2022

fantasai Dec 15, 2022

flackr Dec 14, 2022

fantasai Dec 15, 2022

ydaniv Dec 17, 2022

fantasai Dec 20, 2022

ydaniv Dec 22, 2022 •

edited

flackr Feb 2, 2023

ydaniv Feb 3, 2023

fantasai Feb 6, 2023

flackr Dec 14, 2022

fantasai Dec 15, 2022

flackr Dec 14, 2022

flackr left a comment

flackr Feb 2, 2023

flackr Feb 2, 2023

fantasai Feb 6, 2023

fantasai Feb 6, 2023

[scroll-animations-1] separate animation-range and animation-delay #7901 #8219

[scroll-animations-1] separate animation-range and animation-delay #7901 #8219

Conversation

fantasai commented Dec 13, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ydaniv Dec 22, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

flackr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ydaniv Dec 22, 2022 •

edited