[web-animations-1] [scroll-animations-1] Support automatic duration scroll animations #4862 #4890

flackr · 2020-03-20T19:39:46Z

Change the implicit handling of auto duration animations to use the duration of the supplied timeline, giving ScrollTimeline an implicit duration of 100s corresponding to 100% of their progress.

I think this is about the minimum that could be done to support the use case in #4862 and also doesn't significantly complicate web animations. While I like the idea of supporting arbitrary percentages specified in the future, it's easy to see how the specified duration 'auto' implicitly maps to 100% of the duration.

The only change to existing behavior is that no supplied animation duration would result in an infinite duration (from the DocumentTimeline) rather than 0 duration as defined today.

…croll-animations Change the implicit handling of auto duration animations to use the duration of the supplied timeline, giving ScrollTimeline an implicit duration of 100s corresponding to 100% of their progress.

flackr · 2020-03-20T19:43:58Z

scroll-animations-1/Overview.bs

 };
 </pre>

 A <dfn>scroll timeline</dfn> is an {{AnimationTimeline}} whose time values are determined
 not by wall-clock time, but by the progress of scrolling in a [=scroll container=].
+The {{AnimationTimeline/duration}} of a <a>scroll timeline</a> is 100s to provide


It might be nice if this were still a percentage but the definition of time values already suggests the correspondence to milliseconds is weak.

scroll-animations-1/Overview.bs

majido

This looks very reasonable to me. I am surprised how little change it required.

The only change to existing behavior is that no supplied animation duration would result in an infinite duration (from the DocumentTimeline) rather than 0 duration as defined today.

What is the web-compat impact of this?

web-animations-1/Overview.bs

flackr · 2020-04-03T14:15:59Z

This looks very reasonable to me. I am surprised how little change it required.

The only change to existing behavior is that no supplied animation duration would result in an infinite duration (from the DocumentTimeline) rather than 0 duration as defined today.

What is the web-compat impact of this?

It's actually very minimal, and could be removed if we felt necessary. Previously the value auto for EffectTiming duration would be treated as 0, and with this proposal as is, it would now be infinite. This means if you didn't specify a duration for an animation it would hold its 0 value forever instead of having no effect. I would expect that 'auto' duration animations are extremely rare as it's not currently a meaningful value.

As I was suggesting, we could make an exemption that auto for infinite duration timelines still resolves to 0, which would make it completely backwards compatible with the existing web surface.

Also, resolve start and end delays to 0 until we have a way of representing percentage based start and end delays which can be resolved against a percentage timeline.

…centage timeline.

scroll-animations-1/Overview.bs

web-animations-1/Overview.bs

scroll-animations-1/Overview.bs

web-animations-1/Overview.bs

birtles · 2020-06-12T08:18:01Z

web-animations-1/Overview.bs

+        the {{EffectTiming}} interface. A percentage value is represented as its
+        double value (i.e. 100% returns 1.0).


Doesn't this lose information? i.e. it doesn't roundtrip and it's not possible to tell whether 1.0 represents a percent or a millisecond time?

It's expected that getComputedTiming can lose information though, right? I thought we had settled on the progress being a double in the [0-1] range in our previous discussions.

web-animations-1/Overview.bs

birtles · 2020-06-12T08:22:47Z

web-animations-1/Overview.bs

+    If the <a lt="timeline duration">duration</dfn> of the Animation's
+    <a>timeline</a> is a percentage, a non <code>auto</code> duration will
+    be treated as 0. Future levels of this specification are expected to
+    introduce support for scaling duration, iterations and start/end delays
+    to fill a percentage timeline duration.


We probably should update the paragraph before this, and then describe the syntax for percentages (and how they are encoded as strings).

Also, it seems like the duration of a timeline can't be a percentage?

Hmm, my thinking was that internally we would recognize that the timeline duration is a percentage even though the value by inspection would be 1.0 (consistent with getComputedStyle). However, I'm guessing the issue is that if it's not represented in the WebIDL return value we can't recognize this.

Some options:

Define and use a subclass of AnimationTimeline (i.e. ProgressTimeline) and check the instance type to determine which behavior to apply.

Use a string value for duration

Any other ideas? Any recommendations?

Oh good point. I think it's probably helpful to ask what we want getTiming() and getComputedTiming() to return when we later introduce effects that are a percentage of their parent group's time (or ancestor timeline if we introduced fixed duration document timelines for example).

I think in that case we might want something like:

getTiming().duration to return CSSNumberish, i.e. a double in the case of a fixed time (for compatibility) or a CSSNumberValue to represent a percentage.

getComputedTiming().duration to return a number which is either the resolved duration in ms (in part for compatibility, and in part so we can determine the actual duration for complex group effects) or a value between [0, 1] or [0, 100] to represent a percentage of an auto duration timeline.

What do you think?

I like this, if we do the same for the timeline duration then we can know when a defined duration on the timeline is a time (where time-based values in the animations don't need to be dropped) or a percentage (where we convert time based animations to their respective proportions). I'll work on making this change.

Actually we already specify that the return value from getTiming() must be auto if the duration is specified as auto so we should be returning the string 'auto' from getTiming which will round trip. I still like the idea of using CSSNumberish for the timeline duration though so that we clearly know whether the duration is time-based or progress (percentage) based.

We could consider returning CSSNumberish from computed timing - that would sidestep the issue of converting the percentages to a double value. It will mean changing a lot of values to be CSSNumberish, but this might be cleaner in the long run. WDYT?

I'm not really sure. Once we are able to use percentages that resolve to times (e.g. duration is 50% of my parent group) I wonder if it would be useful to have getComputedTiming() return the actual number of seconds it resolves to? In which case, should percentages that resolve against scroll timelines resolve to pixels?

Unfortunately getComputedStyle doesn't give an entirely clear precedent here since it sometimes resolves percentages (e.g. for width and height) but otherwise doesn't. I guess the intention is that it should always return percentages. So maybe we should return CSSNumberish instead?

It would be interesting to know if anyone else has an opinion on this.

I'm not really sure. Once we are able to use percentages that resolve to times (e.g. duration is 50% of my parent group) I wonder if it would be useful to have getComputedTiming() return the actual number of seconds it resolves to?

I could see this being useful, and might be worth doing.

In which case, should percentages that resolve against scroll timelines resolve to pixels?

This depends on what you consider to be the underlying value of the ScrollTimeline right? It could be pixels but it could also only operate in percentage of scroll or percentage of duration?

Unfortunately getComputedStyle doesn't give an entirely clear precedent here since it sometimes resolves percentages (e.g. for width and height) but otherwise doesn't. I guess the intention is that it should always return percentages. So maybe we should return CSSNumberish instead?

I think returning CSSNumberish and keeping percentages in the computed timing makes sense. One thing that I believe supports this is this note from css-cascade (emphasis mine):

Note: In general, the computed value resolves the specified value as far as possible without laying out the document or performing other expensive or hard-to-parallelize operations, such as resolving network requests or retrieving values other than from the element and its parent.

cc/ @andruud

Leaving percentages intact sounds entirely reasonable.

Although depending on layout in this case is probably less painful than normal, given the snapshotting described in Avoiding cycles with layout, which means we can resolve the percentages against whatever is known from the previous snapshot?

returning CSSNumberish

Note that (from brief inspection of css-typed-om & Blink): there seems to be an "understanding" that a return value of CSSNumberish means you always get a CSSNumericValue. So readonly CSSNumberish attributes would probably ideally be CSSNumericValue attributes. So since this would be the first deviation from this (I think), we should probably specify under which circumstances we can expect a raw double.

Note that (from brief inspection of css-typed-om & Blink): there seems to be an "understanding" that a return value of CSSNumberish means you always get a CSSNumericValue. So readonly CSSNumberish attributes would probably ideally be CSSNumericValue attributes. So since this would be the first deviation from this (I think), we should probably specify under which circumstances we can expect a raw double.

That sounds reasonable. If we were designing this from scratch I think we would always return a CSSNumericValue and it is only compatibility constraints that mean we sometimes need to return an actual number.

web-animations-1/Overview.bs

flackr

I still have to implement the automatic scaling of pure time-based animations and there's an open question on what the best resolution is for allowing timeline duration to be recognized as a percentage.

web-animations-1/Overview.bs

flackr · 2020-06-18T20:10:43Z

web-animations-1/Overview.bs

+        the {{EffectTiming}} interface. A percentage value is represented as its
+        double value (i.e. 100% returns 1.0).


It's expected that getComputedTiming can lose information though, right? I thought we had settled on the progress being a double in the [0-1] range in our previous discussions.

web-animations-1/Overview.bs

flackr · 2020-06-18T20:19:50Z

web-animations-1/Overview.bs

+    If the <a lt="timeline duration">duration</dfn> of the Animation's
+    <a>timeline</a> is a percentage, a non <code>auto</code> duration will
+    be treated as 0. Future levels of this specification are expected to
+    introduce support for scaling duration, iterations and start/end delays
+    to fill a percentage timeline duration.


Hmm, my thinking was that internally we would recognize that the timeline duration is a percentage even though the value by inspection would be 1.0 (consistent with getComputedStyle). However, I'm guessing the issue is that if it's not represented in the WebIDL return value we can't recognize this.

Some options:

Define and use a subclass of AnimationTimeline (i.e. ProgressTimeline) and check the instance type to determine which behavior to apply.

Use a string value for duration

Any other ideas? Any recommendations?

web-animations-1/Overview.bs

…-based.

flackr

I've added the procedure for converting purely time-based animations to progress based and converted the timeline duration to a CSSNumberish so that we can in the future tell a progress based finite timeline from a time based one.

scroll-animations-1/Overview.bs

andruud · 2020-06-24T09:19:48Z

web-animations-1/Overview.bs

-    In this level of this specification, the string value <code>auto</code>
-    is treated as the value zero for the purpose of timing model calculations
+    If the <a lt="timeline duration">duration</dfn> of the Animation's
+    <a>timeline</a> is a percentage, a non <code>auto</code> duration will


Since you just required the duration to be a percentage, do you need to mention non-auto?

I just required the timeline duration to be a percentage, however the non-auto duration refers to the animation duration.

ogerchikov · 2020-07-15T23:37:34Z

web-animations-1/Overview.bs

+    1.   Compute [=start delay=] and [=end delay=] to 0, as it is not possible
+         to mix time and proportions. Future versions may allow these properties
+         to be assigned percentages.
+


Need "otherwise" close? The rest of the bullets are applied when iteration duration is not "auto".

Thanks, done.

ogerchikov · 2020-07-15T23:38:50Z

web-animations-1/Overview.bs

+    <code>|start delay| / |total time|</code>.
+
+1.  Compute [=iteration duration=] to be the result of evaluating
+    <code>|iteration duration| / |total time|</code>.


Need to divide by iteration count.

I think it's correct as is, e.g. with start delay 2, iteration count 5, iteration duration 1, end delay 3:
total time is 2 + 5 * 1 + 3 = 10
iteration duration is calculated as 1 / 10 = 10%

ogerchikov · 2020-07-15T23:46:40Z

web-animations-1/Overview.bs

+
+1.  Compute [=end delay=] to be the result of evaluating
+    <code>|end delay| / |total time|</code>.
+


In this calculation the resulted values sum to 1. However when iteration duration is "auto", the timing values sum to timeline.duration. I think for consistency and correctness the values in both cases should sum to timeline.duration.

Good catch, it's possible timeline duration will not always be 100% and we should match that here. Done.

flackr · 2021-01-07T20:04:17Z

@birtles I've moved all of the web-animations-1 changes to deltas in web-animations-2. @JTensai is currently prototyping this in chromium and I think has not run into any issues. Happy to wait until we have a working implementation to land this but just wanted to confirm that this addresses the main concerns.

birtles

Hi Rob, I'm really sorry. I wrote a long comment here because I think as we add this to level 2 we need to work out how it integrates with groups.

birtles · 2021-01-08T00:13:33Z

web-animations-2/Overview.bs

+Add:
+
+> The <dfn lt="timeline duration">duration</a> of a timeline gives the
+> maximum value a timeline may generate for


Nit: for its current time?

birtles · 2021-01-08T01:24:03Z

web-animations-2/Overview.bs

+> [=timeline current time|current time=]. This is used to calculate the
+> [=iteration duration=] when the string <code>auto</code> is specified such that
+> the animation fills the available time.


A few thoughts here:

Firstly, this is part of the model description, as opposed to the API, so we generally try to phrase things in terms of the concepts rather than the specific interface types. (I'm not sure if that's a good idea after all, but that's the state of affairs at the moment.)

Secondly, I think we need to say where the auto value is specified -- in this case I think we are talking about the target effect of an animation association with the timeline. However...

Thirdly, in level 2 of the spec, auto is also used to allow groups to have a duration calculated based on the lengths of their children. At the model level, auto means "use the intrinsic iteration duration".

So, I think this sentence should probably be something like:

This is used in calculating the intrinsic iteration duration of the target effect of animations associated with the timeline.

Which brings us to something I think you might not want to hear: I think we probably need to specify how these different cases interact.

I wonder if can do something like the following:

Redefine the intrinsic iteration duration as being either a number or a percentage/proportion or possibly a calc expression of both.

Define the intrinsic iteration duration of keyframe effects (or all animation effects that don't supply their own definition for intrinsic iteration duration) as being 100% (instead of 0s).

Rework the definition of the intrinsic iteration duration of group effects to similarly produce either a number or proportion or potentially a calc() if we allow that.

In a sense, these steps produce a bottom-up initial calculation of the target effect's intrinsic iteration duration.

(Optionally define the timeline duration of a document timeline as being zero instead of null since I think that might make the spec simpler if there's no particular need for null.)

Define a "resolve computed intervals" procedure where we start with the target effect of an animation, and resolve its duration, start delay, and end delay based on the particular combination of its:

Timeline duration

Specified iteration duration or intrinsic iteration duration

Specified start delay and end delay

This would be similar to the conversion procedure defined in this spec. In the simple case, nothing would be need to be resolved as everything would already be in milliseconds. Similarly, when we have everything in percentages, there would be nothing to do.

In other cases, where we have a millisecond duration timeline (e.g. DocumentTimeline with its 0ms duration) and proportion times, we would resolve the proportions to milliseconds. (This would allow a KeyframeEffect with an auto duration to continue producing a resolved duration of 0s.)

In yet other cases where we have a percentage timeline and millisecond times, we would convert the milliseconds to percentages as we have in the conversion algorithm in this spec.

Then of course, there are the odd cases where we have a mix we don't support and where we need to use some sensible behavior. I think it's worth at least thinking about how we could support calc(50% + 2s).

Recursively apply this behavior to the target effect's child effects.

I'm really sorry. I know you wanted to keep this patch as simple as possible just to get this working for scroll timelines, but I think we need to work out how this integrates with group effects.

On the positive side, if the above approach works, we'll have solved percentage based timing in general and made something really useful, I think.

I think it would also extend naturally to other use cases like KeyframeEffects where the keyframe offsets are specified in milliseconds. We would simply plug those values into the calculation of the intrinsic iteration duration of the keyframe effect and the rest would just work.

I should clarify step 6:

Recursively apply this behavior to the target effect's child effects.

I don't think we'd need to actually write an algorithm to recursively visit the children. Instead we could just write a definition for computed iteration duration, computed start delay etc. in terms of their parent time source's intrinsic iteration duration and then we'd naturally get the recursive behavior (i.e. the bottom-up followed by top-down traversal).

Hi Brian,
I've jumped in to assist Rob on the spec work and have a new pull request (#6337), which hopefully addresses the outstanding issues.

Some of the key changes:

intrinsic iteration duration updated to be either a percent or time. In the case of a progress based timeline, the percent is simply 100% / iteration_count. Note that in the future, if start and end delay are updated to allow percentages, the intrinsic iteration duration becomes (100% - start - end) / iteration_count. Once start and end percentages are supported, we will need to be able to handle start + end > 100%, which would otherwise result in a negative intrinsic iteration duration. This should be fairly easy to handle. Just raising the issue now so that we don't lose track of it.

Updated to procedure for calculating the intrinsic iteration duration to support group/sequence effects as well as progress based timelines.

Note that mixing times and percentages opens up some awkward edge cases that are not easily addressed (examples below). Ultimately, we can easily convert form entirely time based to percentage based. The inverse is only possible if knowing the effect end time. For now, I was planning to stick with Rob's suggestion of start and end being set to 0 if the timeline is progress based.

Currently the iteration duration can be a time or 'auto'. In the future, we could extend to time 'auto' or percent. I would prefer to defer introducing percentages outside of 'auto' to avoid complications that would be introduced until all of the details can be worked out. The value for effect end time depends on iteration duration, which in turn could be the intrinsic iteration duration if 'auto'. The intrinsic iteration duration in turn can depend on effect end time.

Let's start with a few cases that would work, and them move to the ugly cases:

Case 1:

.anim {
animation: parallax 1s 0.25s scroll-timeline;
}
.anim2 {
Animation: parallax 2s scroll-timeline;
}

Here everything is time based, so the conversion to percentages for use with a progress based scroll timeline is trivial.

anim: iteration duration = 100% * (1s / 1.5s) = 66.67%, start delay = end delay = 100% * 0.25s / 1.5s = 16.67%
anim2: iteration duration = 100%, start delay = end delay = 0%

Case 2:

.anim {
animation-name: parallax;
animation-delay: 20%; /* once supported as a percent */
Animation-timeline: scroll-timeline;
}

intrinsic iteration duration = 100% - 20% = 80% = iteration duration

Case 3:

.anim {
animation-name: parallax;
animation-duration: 1s;
animation-delay: 20%;
}

Now we would need to be prepared to a bit more work to resolve the timing by collecting times and percentages.

end time = 1s + 20% = 100% ==> 1s = 80% ==> 1.2.s = 100%.

Note: at this stage we can get inconsistent timings (e.g. 0s animation + delay != 100%).

Case 4:

.anim {
animation-name: parallax;
animation-duration: 75%;
animation-delay: 1s;
}

Similar approach to case 3.

end time = 75% + 1s = 100% ==> 1s = 25% ==> 4s = 100%.

Case 5:

.anim {
animation-name: parallax;
animation-delay: 2s;
Animation-iteration-count: 2;
}

Now for an ugly case.

end time = 2*(intrinsic iteration duration) + 2s = 100%
==> 2*((100% - 2s))/2 + 2s = 100%
==> 100% = 100%

Here the intrinsic iteration duration is arbitrary. It may make sense to use the minimum solution (0s/0%) in this case. I welcome further discussion in this area, but would prefer to defer allowing mixing of percentages and times to a followup pull request. I believe have a pretty solid base, which can be extended in a way that won't require backpedaling.

Hi Kevin,

Thank you so much for following up on this. Unfortunately I'm going to be quite busy for the next few days. Do you mind if I get back to you on this after that? Please feel to ping me if I'm taking too long or if you have any particular time constraints.

Thanks for your patience on this. I've finally reviewed #6337 and it looks good.

Responding to your comment,

Case 1:

.anim {
animation: parallax 1s 0.25s scroll-timeline;
}
.anim2 {
Animation: parallax 2s scroll-timeline;
}

Here everything is time based, so the conversion to percentages for use with a progress based scroll timeline is trivial.

anim: iteration duration = 100% * (1s / 1.5s) = 66.67%, start delay = end delay = 100% * 0.25s / 1.5s = 16.67%
anim2: iteration duration = 100%, start delay = end delay = 0%

I'm curious why start and end delay end up being made the same. Shouldn't the 0.25s from the animation declaration be mapped to start delay only?

Overall though it's looking great. I'm a bit uncomfortable about having combinations of content that don't work now but which we expect to work in future.

It would be good to add another PR at some point filling out those cases. I'd even be to say, for example, when an animation is directly or indirectly associated with a progress-based timeline, if it uses a combination of percentages and times, we just ignore the times (i.e. use their default values) if need be. At least that's consistent, I guess.

Maybe that's roughly equivalent to what you have, though. From what I tell though, with #6337 if you specified duration 5s, start delay 5%, end delay 2s, we'd end up ignoring both start delay and end delay as opposed to simply ignoring the time-based end delay.

Oops...yes case 1 should be a 1.25s animation which then maps to 100% so that the iteration duration and start delay can be converted to percentages.

Integrated progress based scroll timelines with animations and effects. Effect timing model updated to handle both time based timelines and progress based timelines Spec change this CL is based on: w3c/csswg-drafts#4890 Change-Id: I6ace6a8c8a94c117754b5c5fb632b7a85088726e

Integrated progress based scroll timelines with animations and effects. Effect timing model updated to handle both time based timelines and progress based timelines Spec change this CL is based on: w3c/csswg-drafts#4890 Change-Id: If4bc889f8fdcc1ebe393f41b8788f6bd1ddec051

Integrated progress based scroll timelines with animations and effects. Effect timing model updated to handle both time based timelines and progress based timelines Spec change this CL is based on: w3c/csswg-drafts#4890 Bug: 1140602 Change-Id: If4bc889f8fdcc1ebe393f41b8788f6bd1ddec051

flackr · 2021-06-23T03:52:23Z

Closing as this has been continued in #6337

Integrated progress based scroll timelines with animations and effects. Effect timing model updated to handle both time based timelines and progress based timelines Spec change this CL is based on: w3c/csswg-drafts#4890 Bug: 1140602 Change-Id: If4bc889f8fdcc1ebe393f41b8788f6bd1ddec051 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2925975 Reviewed-by: Kevin Ellis <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Commit-Queue: Jordan Taylor <[email protected]> Cr-Commit-Position: refs/heads/master@{#895253}

Integrated progress based scroll timelines with animations and effects. Effect timing model updated to handle both time based timelines and progress based timelines Spec change this CL is based on: w3c/csswg-drafts#4890 Bug: 1140602 Change-Id: If4bc889f8fdcc1ebe393f41b8788f6bd1ddec051 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2925975 Reviewed-by: Kevin Ellis <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Commit-Queue: Jordan Taylor <[email protected]> Cr-Commit-Position: refs/heads/master@{#895253}

…do not provide a time_range, a=testonly Automatic update from web-platform-tests Added support for scroll timelines that do not provide a time_range Integrated progress based scroll timelines with animations and effects. Effect timing model updated to handle both time based timelines and progress based timelines Spec change this CL is based on: w3c/csswg-drafts#4890 Bug: 1140602 Change-Id: If4bc889f8fdcc1ebe393f41b8788f6bd1ddec051 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2925975 Reviewed-by: Kevin Ellis <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Commit-Queue: Jordan Taylor <[email protected]> Cr-Commit-Position: refs/heads/master@{#895253} -- wpt-commits: dd79e0c4132d7b749309998152342b1e21f7983e wpt-pr: 29295

flackr requested a review from birtles March 20, 2020 19:39

flackr commented Mar 20, 2020

View reviewed changes

flackr commented Mar 23, 2020

View reviewed changes

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

flackr requested a review from majido March 23, 2020 16:45

majido reviewed Mar 31, 2020

View reviewed changes

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

This was referenced Apr 9, 2020

[css-animations-2] Proposal: Time-based Keyframe Animations #4907

Open

[scroll-animations] Support series of scroll offsets #4912

Closed

flackr added 5 commits May 13, 2020 15:38

Merge branch 'master' into animation-duration-auto

d2902ce

Merge branch 'master' into animation-duration-auto

37e981f

Merge branch 'master' into animation-duration-auto

9720857

Use percentage duration resolved for computed timing.

46b051c

Also, resolve start and end delays to 0 until we have a way of representing percentage based start and end delays which can be resolved against a percentage timeline.

Fix definition and resolve iteration duration to 0 if non-auto on per…

2449252

…centage timeline.

flackr mentioned this pull request Jun 10, 2020

[scroll-animations] Support progress-based animations on finite timelines #4862

Closed

ogerchikov reviewed Jun 10, 2020

View reviewed changes

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

birtles requested changes Jun 12, 2020

View reviewed changes

flackr added 2 commits June 18, 2020 15:05

Merge branch 'master' into animation-duration-auto

3928ae8

Maintain backwards compatibility for auto duration and other comments.

fc24414

flackr commented Jun 18, 2020

View reviewed changes

flackr added 2 commits June 19, 2020 14:00

Define the procedure for converting time-based animations to progress…

d148415

…-based.

Split timeline duration of scroll timeline into separate section.

5324d25

flackr commented Jun 19, 2020

View reviewed changes

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

andruud reviewed Jun 24, 2020

View reviewed changes

frivoal added css-animations-1 Current Work web-animations-1 labels Jul 14, 2020

ogerchikov reviewed Jul 15, 2020

View reviewed changes

flackr added 3 commits July 16, 2020 02:12

Return CSSNumberish from computed timing allowing percentages.

e572251

Merge branch 'master' into animation-duration-auto

e713294

Move web-animations changes to web-animations-2 diffs.

8c19960

birtles requested changes Jan 8, 2021

View reviewed changes

Base automatically changed from master to main February 2, 2021 19:45

chromium-wpt-export-bot mentioned this pull request Mar 25, 2021

Added support for scroll timelines that do not provide a time_range web-platform-tests/wpt#28251

Closed

kevers-google mentioned this pull request Jun 1, 2021

[web-animations-2] [scroll-animations-1] Support automatic duration scroll animations #6337

Merged

chromium-wpt-export-bot mentioned this pull request Jun 9, 2021

Added support for scroll timelines that do not provide a time_range web-platform-tests/wpt#29295

Merged

flackr closed this Jun 23, 2021

flackr mentioned this pull request Mar 4, 2022

[scroll-animations-1] CSSNumberish time values to represent types. #7102

Closed

		the {{EffectTiming}} interface. A percentage value is represented as its
		double value (i.e. 100% returns 1.0).


		1. Compute [=end delay=] to be the result of evaluating
		<code>\|end delay\| / \|total time\|</code>.

[web-animations-1] [scroll-animations-1] Support automatic duration scroll animations #4862 #4890

[web-animations-1] [scroll-animations-1] Support automatic duration scroll animations #4862 #4890

Conversation

flackr commented Mar 20, 2020 • edited Loading

Choose a reason for hiding this comment

majido left a comment

Choose a reason for hiding this comment

flackr commented Apr 3, 2020

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

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

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

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 commented Jan 7, 2021

birtles 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

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 commented Jun 23, 2021

flackr commented Mar 20, 2020 •

edited

Loading