[csswg-drafts] [scroll-animations-1] Handling changed size/position in current frame (#8694)

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

== [scroll-animations-1] Handling changed size/position in current frame ==
In issue #5261 we defined a mechanism for ensuring that scroll and view timelines that were discovered during style and layout were given an opportunity to produce a current time for the frame in which they were first rendered, however with [view timeline ranges](https://www.w3.org/TR/scroll-animations-1/#view-timelines-ranges) being usable from both `animation-range` and from keyframes, the particular progress of an animation depends on layout.

For example, consider the following ([demo](https://jsbin.com/pudexek/edit?html,css,output)):
```html
<style>
.subject {
  view-timeline: subject;
}

.shifted {
  top: 120vh;
}
.grown {
  height: 300px;
}

@keyframes slide {
  entry 0% {transform: translateY(100vh);}
  exit 0% {transform: translateY(0);}
}

#animated {
  animation: slide linear;
  animation-timeline: subject;
}
</style>
<div class="subject"></div>
<div id="animated"></div>  
<button class="shift">Shift</button>
<button class="grow">Grow</button>
<script>
document.querySelector('.shift').addEventListener('click', () => {
  document.querySelector('.subject').classList.toggle('shifted');
});

document.querySelector('.grow').addEventListener('click', () => {
  document.querySelector('.subject').classList.toggle('grown');
});
</script>
```

When the `shifted` or `grown` classes are added (e.g. by clicking the buttons) we need to update the offset of the `exit 0%` keyframe as well as invalidate the animation and calculate the new position for the `#animated` box.

We have two options:
1. Allow animation to be out of date on the frame in which geometry changes occur. Schedule another frame and allow for some flicker.
2. Detect changes in the geometry and allow rerunning style and layout. We could do this in a similar way to how we re-run the lifecycle for newly detected animations (see #5261).

I think that unless an animation caused the animation to change I would not expect a flicker when a style change results in the subject moving. As such, I suggest pursuing option 2. More concretely, after running resize observers (to take into account developer derived sizes), we would need to check if the animation constraints have changed (in addition to checking for new scroll timelines as we already do) and if so rerun style and layout to incorporate the updated animations. This is not ideal for performance but hopefully will not happen often.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 6 April 2023 19:45:30 UTC