[csswg-drafts] 'effective time range' for timeRange: auto has some undesirable behaviors (#4346)

stephenmcgruer has just created a new issue for https://github.com/w3c/csswg-drafts:

== 'effective time range' for timeRange: auto has some undesirable behaviors ==
For [effective time range](https://wicg.github.io/scroll-animations/#efffective-time-range-algorithm), the spec currently says:

> If the timeRange has the value "auto",
> The effective time range is the maximum value of the target effect end of all animations directly associated with this timeline.
> 
> If any animation directly associated with the timeline has a target effect end of infinity, the effective time range is zero.

There are a few questions we can ask about this.

**If there are no associated animations**
```
console.log(new ScrollTimeline({scrollSource: scroller}).currentTime);
```
What is the value of the above? We have to multiply the result by `effective time range`, but that isn't specified when there are no associated animations.

This could probably be fixed by just making it either 1 (so its a scroll fraction by default) or making it the scroll range (so it maps to scroll offset), but there's another issue...

**When a new animation is associated with the same timeline**
```
const timeline = new ScrollTimeline({scrollSource: scroller});
new Animation(new KeyframeEffect(target, keyframes, { duration: 1000; }), timeline).play();
// Some time later...
new Animation(new KeyframeEffect(other_target, other_keyframes, { duration: 2000; }), timeline).play();
```

When the second animation is created, the ScrollTimeline's currentTime suddenly jumps and as such so would the visual output of the first animation.

**The problem with timeRange: auto**

The idea behind `timeRange: auto` makes a lot of sense - most of the time, you want the output of the ScrollTimeline to be linearly mapped to the possible values for whatever animation is using it. But the way it is specified falls apart in practice - under the case of multiple animations in particular.

Arguably what a web developer really wants is to say "I'm using a finite timeline so I don't actually care about the duration of my effect; just make it match the timeline range". But we implemented that in a backwards manner; mutating the timeline to fit the effect duration rather than the effect duration to fit the timeline.

I don't have a specific proposal for fixing this yet; a naive approach would be to allow a special value for [iteration duration](https://drafts.csswg.org/web-animations-1/#iteration-duration) which causes it to be taken from the timeline range, but this likely falls apart in the face of iteration count, etc.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4346 using your GitHub account

Received on Thursday, 19 September 2019 05:42:14 UTC