W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2020

Re: [csswg-drafts] [scroll-animations] Support progress-based animations on finite timelines (#4862)

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Thu, 07 May 2020 06:57:18 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-625067968-1588834637-sysbot+gh@w3.org>
Thank you for all the time you put into this. I really appreciate it. I mostly agree but was imaging a slightly different approach, although perhaps it is really just different phrasing.

> In the new model the animation continues to produce a progress value while it can receive either progress or time from its timeline.

Nit: We might be saying the same thing but I'm getting confused because animations don't produce progress.

> * Animations can be configured as either progress-based or time-based but not a mix of both.
>   * In other words, both duration and delays should be in the same unit. (later we can explore how this restriction can be relaxed in future)
>   * Current time will match this unit.
> * Animation would continue converting their current time into simple progress values to be fed into keyframe effect.

Nit: Likewise here, animations don't have a duration or delay, effects do. Similarly, animations don't convert current time into simple progress, effects do.

But  possibly we're still thinking the same thing.

The approach I had in mind is maybe a little more bottom-up however. Something like:

1. Starting with keyframes, then working up to effects, then parent effects, and then animations we pass up an intrinsic duration which is either a time value, or unresolved.
    * For the keyframes, if all the offsets are times, we'd take the maximum value and pass that up. Otherwise, if we have a combination of percentages and times, we'd pass up unresolved.
    (This, incidentally, allows having a mixture of times and percentages in some cases but would require special handling when the resolved offsets would swap positions.)
    * For keyframe effects, if they have a duration specified as a time (or their keyframes produce one), we'd pass that up to the parent effect. Otherwise we'd pass up unresolved.
    * For group effects, we'd use the rules already defined there to calculate an intrinsic duration. E.g. a parallel group would take the max end time of its children, but note that if any of its children had an unresolved duration, it would pass up unresolved. Similarly for sequence effects. Note that these effects can also specify a fixed iteration duration in which case we'd pass that up instead.
    * For the root effect, we pass its intrinsic duration up to the animation.
1. At the animation we negotiate a resolved animation duration something like the following:
    * If the received duration is a time and we have a time-based timeline → Use received time
    * ... received unresolved + time-based timeline → Invalid as per third row in Majid's table. Using infinity might make sense (see below).
    * ... received duration + progress-based timeline → Do mapping as suggested by Majid's "Assigning time-based animations to progress-based timelines"
    * ... received unresolved + progress-based timeline → Use '100%' as duration
1. Pass the resolved duration back down the tree and resolve any unresolved / percentage values.
    * If we're passing down '100%' as the duration then all our computed percentage values will themselves produce percentage values. The `currentTime` of the animation would also be a percentage.
    * If we're passing down a percentage and we have time based durations at some point we have a problem. We could just treat those times as zero and effectively drop those effects? (That might even be useful as a way of show some effects only when running on a time-based timeline?)

* If we were later to introduced fixed-duration time-based timelines, presumably percentage measures would still work then. In that case, the current DocumentTimeline might just be an instance of such a timeline with an infinite duration. In that case, using infinity for the invalid case would make sense (it would be useless, but consistent and understandable).
* I agree with exploring Typed OM for API ideas.

GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4862#issuecomment-625067968 using your GitHub account
Received on Thursday, 7 May 2020 06:57:19 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:06 UTC