-
Notifications
You must be signed in to change notification settings - Fork 717
[scroll-animations-1] Also rerun style/layout for changed timeline ranges #8704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Co-authored-by: fantasai <fantasai.bugs@inkedblade.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
we run and we run an additional step to recalculate styles and update layout. | ||
As we only gather stale timelines during the first style and layout calculation, | ||
|
||
Note: We check for layout changes after dispatching any {{ResizeObserver}}s intentionally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... but this means that ResizeObserver sees an irrelevant layout state vs. what we actually intend to render?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct. It's a tradeoff I think. Either:
- Run before ResizeObserver, then any changes to sizes of content made by ResizeObserver may not be handled by scroll driven animations, but ResizeObserver will see layout driven animation results.
- Run after ResizeObserver, then layout animations may not be fully up to date when calling ResizeObserver, but view timelines will be able to observe resizeobserver derived sizes.
Given that ResizeObservers are designed for establishing the size of elements, I feel like view timelines should be updated to reflect the final resize observer output. The converse, animating layout firing ResizeObservers in response to scroll seems like an anti-pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're going to want to use the same mechanism and invalidation for anchor positioning. Chatting with @bfgeek we thought after ResizeObserver would be more in line with the use cases.
…nce' into scroll-animations-layout-dependence
Fixes #8694.