W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2019

Re: [csswg-drafts] [web-animations-1] Make animations become idle when they have an inactive timeline (#2066)

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Dec 2019 13:48:14 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-567038463-1576676892-sysbot+gh@w3.org>
> To eliminate a requirement to handle unresolved current time we proposed removing scrollTimeline.fill attribute.

I don't think this is the right reason to drop the fill attribute. We still have to handle unresolved current times one way or another.

However, I think a good reason for dropping the fill attribute is the scenario described in the second paragraph of the first comment in this issue and in Majid's comment above this one.

> Instead, resolve the current time for cases when scroll is outside of start and end offsets as follows:
> * If scrollTimeline.startScrollOffset is specified and scroll < startScrollOffset, current time = (0 -  epsilon) (or -infinity).
> * If scrollTimeline.endScrollOffset is specified and scroll > endScrollOffset, current_time = (duration + epsilon) (or +infinity).

We should make this magic explicit and introduce the states described in the first comment in this issue.

> As a result, we extended scroll timeline inactiveness definition to include scrollTimeline.startScrollOffset == scrollTimeline.endScrollOffset condition and specified the following behavior of animations in regards to handling inactive timelines:
> * If animation is playing and timeline becomes inactive, the animation should have no effect applied as if animation.play() was never called.

What does this mean? Is it equivalent to canceling? Is the start time preserved?

> * As soon as the timeline becomes active, the animation should start playing again without user intervention.

Right, this is use case 1 from the first comment in this issue.

> @majido brought a case that perhaps inactive timelines should be handled similarly to null timelines.

Yep, that same suggestion is made earlier in this thread.

> > This step makes the behavior when an animation’s timeline becomes inactive consistent with when it is disassociated with a timeline. Furthermore, it ensures that the only occasion on which an animation becomes idle, is when the procedure to cancel an animation is performed.
> But I think the [current prose](https://drafts.csswg.org/web-animations/#responding-to-a-newly-inactive-timeline) behaves differently, in particular it causes the animation to be in the `paused` play state when timeline becomes inactive as opposed to the `idle`.

I think that's what the text is saying--it should be come `paused`, not `idle`. I think Firefox might have a bug there, or maybe the spec text for the two cases just got out of sync.

Going through this issue and all the others, I think we're converging on something like the following approach:

* Drop fill modes from `ScrollTimeline`
  * This should fix #4325 and may partially address #4324 (since we would presumably no longer enter the `idle` state).
* Introduce the additional timeline states mentioned in the first comment in this thread (e.g. before-start, after-end, in range).
  * This would address #4347 too (and possibly #4341).
* Introduce a distinction between montonic timelines (`DocumentTimeline`) and finite timelines (`ScrollTimeline`). Define it such that the null timeline is a finite timeline.
* Drop the invariant about being only able to set the hold time or start time when we have an inactive timeline.
* When attaching an active timeline or when an inactive timeline becomes active, always prioritize using the hold time over the start time (that is we re-calculate the start time from the hold time if they are both set, then clear the hold time), but we preserve both for the sake of representing paused-ness.
  * I think this _might_ happen to fix #2048 too.
* Make the play procedure differentiate between different types of timelines such that for finite timelines, if the current time is unresolved we effectively set the start time to zero, ignoring the current state of the timeline. We could possibly pass a flag for this and address #2051 at the same time. (This is a bit awkward and needs more thought. If we want to allow the `startTime` to represent an offset from the timeline in this case, we will need different logic for pausing/unpausing.)
  * This should fix #2075 and is basically (B) from what Majid suggested there.

So the last point is the main one that needs work and one of the questions it raises is whether or not it is ever useful to have an animation that runs at some offset from a fixed timeline (i.e. whether it is ok to simply always make `startTime` zero). I think it is preferable if we can keep `startTime` having some meaning. Being able to seek a scroll animation seems useful, and giving `startTime` some meaning for finite timelines makes the model a little less awkward.

However, it raises questions about how pausing/unpausing works since normally we'd recalculate the `startTime` from the timeline time then. Pausing/unpausing with finite timelines is already weird though, so maybe it doesn't matter too much.

We also still need to check the 6 use cases in the start of this issue are addressed by this.

GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2066#issuecomment-567038463 using your GitHub account
Received on Wednesday, 18 December 2019 13:48:15 UTC

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