Skip to content
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

[scroll-animations-1] Allow specifying small/large viewport for ViewTimelines that use the root viewport as scrollport #11615

Open
ydaniv opened this issue Jan 30, 2025 · 1 comment

Comments

@ydaniv
Copy link
Contributor

ydaniv commented Jan 30, 2025

ViewTimelines depend on the size of the scrollport, and in cases where that is the root viewport, this is a dynamic value that may change, and when it changes this causes a visual jump in animations.

This causes a visual nuisance that is avoided when authors use JS-based polyfills by using either the small or large viewport units, but it's currently not possible in the native implementation.

So, proposing to allow authors to specify whether to use small/large viewport units, which will only take effect when used with the root scroller.
Adding a new property to ViewTimelineOptions, (name TBB) unit-size with values small, large, and auto.

cc @bramus @flackr @fantasai

@bramus
Copy link
Contributor

bramus commented Jan 31, 2025

TBH, I’m fine with a jump in animation as the viewport changes. It’s inherent to a resize, which can also happen on desktop if a user does it.

That said, I’m wondering if we could reuse the view-timeline-inset for this somehow. I tried hacking my way into this by dynamically updating the inset based on which viewport is currently being used: https://codepen.io/bramus/pen/GgKeEXv/021f4a9770af6613ea6edb57c61b2cf9

While I can calculate the difference between the large and small viewports and adjust the offsets dynamically based off of that, there’s also the issue that the origin of the viewport relative to the entire screen changes as the viewport size changes. So ideally, you’d have adjust a bit at the top and bit at the bottom in order to get non-jumpy behavior.

I think you can get to it using the new safe-area-max-inset-bottom but I have not dug into that (yet).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants