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: Majid Valipour via GitHub <sysbot+gh@w3.org>
Date: Tue, 10 Dec 2019 02:04:05 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-563576690-1575943444-sysbot+gh@w3.org>
## Removing ScrollTimeline fill

I support removing `ScrollTimeline.fill`. It makes sense and improves quite a few thing:
 - The current fill property actually does not work as expected in combination with AnimationEffect.fill. See #4325  for more info on this.
 - Once removed, we no longer need to [special case the end scroll offset `auto` to be inclusive](https://github.com/WICG/scroll-animations/issues/19#issuecomment-460680068)
-  Author are able to control the animation value in the before/after portion of scrollRange using AnimationEffect.fill
- As a minor benefit, with this change the timeline is no longer considered "inactive" for a valid scroller that is outside scrollRange. This limits "inactive" to only occur for more specific and rare cases. I think this is a good side benefit of this change. More on this below.

## Inactive Timeline Behavior

If we apply the above change to fill then timeline in-activeness become limited to the case where
the scroll timeline scroll source element is null or not a valid scroller (e.g., `overflow: visible`).

One interesting case that I like to focus here is a scroller with `overflow:auto` whose content changes overtime. Consider such a scroller that (1) its content initially overflowing, then at some point (2) its content shrinks so it no longer overflows, and finally (3) its content grows again so that the scroller overflows again. I believe if scroll timeline can handle this correctly most other cases would naturally follow. Which is why I think it is a good example.

Per [above comment](https://github.com/w3c/csswg-drafts/issues/2066#issuecomment-557630869), ideally we went for scroll-linked animation at (1)  to have an effect according to the scroll offset, at (2) to have no effect, at (3) to again have effect according to the scroll offset. All of these without requiring authors to anticipate and care about the size of the scroller inner content.

Also my preference is if we can have ScrollTimeline with none-scrolling source to behave similar to a null timeline. The following note in the spec suggests this was also the intent:

 > 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`.

My tests with Firefox nightly suggests that Gecko behaves very closely to what I would think is the most desired behavior when timeline is switched between a null and and active timeline (e.g., `document.timeline`).

[Here](https://codepen.io/majido/pen/RwNrBxp) is a simple code pen that shows this.

A. An animation with an active timeline plays as expected.
B. If animation.timeline is set to null, animation goes into `idle` and has no effect.
C. As soon as animation timeline is set to document.timeline, animations starts playing again with play state `running` 
C**. Same as C, but if animation was "paused" when timeline changes from null to active, the animation goes from idle to "paused".

Basically, when timeline goes from active<=>null, the animation goes from paused/running <=> idle and back as expected without any action from the author. I think timeline going from active to inactive should behave the same.


GitHub Notification of comment by majido
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2066#issuecomment-563576690 using your GitHub account
Received on Tuesday, 10 December 2019 02:04:07 UTC

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