[csswg-drafts] [scroll-animations] Behavior of scroll-linked animations in the first frame (#5261)

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

== [scroll-animations] Behavior of scroll-linked animations in the first frame ==
As specified currently, if the author manages to create a `ScrollTimeline` _before_ the first frame has been produced, then:

 - When the [timeline is sampled](https://drafts.csswg.org/scroll-animations-1/#avoiding-cycles), layout will not have have happened yet, hence:
  - The source will _not_ have a CSS layout box, so the timeline is [inactive](https://drafts.csswg.org/scroll-animations-1/#phase-algorithm) for that frame, and there is no effect value.
 - The next frame, the timeline is sampled again, and this time layout _has_ run, so the source now has a layout box, and the timeline is active.

This means there is an initial "flash of no effect value" before the animation takes effect on frame 2.

For the JS API, we could probably mitigate this without any _technical_ difficulty by letting `ScrollTimeline` constructor force a style recalc and layout, and then sample once immediately.

For the CSS API, it's quite a bit worse, since it's the style calculation _itself_ that discovers that a `ScrollTimeline` is needed. In other words, we're already standing in the middle of style recalc when creating `ScrollTimelines`, so we can't force style and layout at that time.

So the question is how to deal with this.

1. Accept the limitation
2. Somehow do multiple passes of style/layout to get the information we need
3. Provide a reasonable default and give the author tools to tweak the initial phase of the timeline
4. Something else

@birtles @flackr @lilles @majido

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

Received on Thursday, 25 June 2020 10:06:55 UTC