@bramus Were there ever pure CSS view transitions discussed? It would be cool to be able to say “here are two different states, create a view transition between them” and then use any CSS animation via any trigger to run it.
I think I saw multiple demos, where there was JS added only as something to trigger the view transitions. If this was available purely via CSS, I think it could be a powerful way to do various effects, often potentially more performant.
You are most likely already familiar with the first part of this concept, as that one got implemented by Maxi Ferreira about a year ago and got shared A LOT (we even featured it in last year’s #GoogleIO!)
The only thing that changes between the two states is the classList on the .card, which applies a different grid-template. View Transitions take care of moving everything around. Very powerful stuff.
(And yes, that was DevTools used to scrub through the animations there)
That said: In Jake’s demo the approach works fine as he can apply the touch-action: none on the draghandle itself.
In my demo I need to conditionally set it based on the scroll offset, drag direction, and card state … which doesn’t work as it gets eval’d before pointerdown.
Looking to other solutions, I turned to what I know very well: Scroll-Driven Animations. The idea is to let all VT animations play but set their timeline to a ScrollTimeline.
That way they don’t tick forwards by time but by you scrolling.
It works, but one big issue though: once the animations reach 100% the View Transition finishes. Because of that, you only get to see the Scroll-Driven View Transition only once.
That also required me to check the direction you are going in: are you expanding or contracting the card? Depending on that, the VT’s animations need to be reversed.
I also added scroll snapping to the code. I’ll spare you the details but this was quite difficult to get right, especially with the DOM already having changed underneath the VT running.
Essentially, I inject snapping boxes that match the expanded layout. Hacky, but it works.
This one works fine on both touch and non-touchy devices, has momentum scrolling, snaps, … just a bit stupid that you need both a Scroll-Driven Animation and a scroll listener.
The version that uses a scroll listener is pretty straightforward: constantly check the offsetTop on scroll. When in range start or update the VT. When out of range, clean up the VT (if any).
It uses update logic similar as the touch version.
The version with a true Scroll-Driven Animation is a bit more complicated: it doesn’t create a ScrollTimeline that is used as the timeline for the VT animations but instead it creates a dummy scroll-driven animation on root whose progress is tracked.
Using the trackProgress function from my @bramus@front-end.social/sda-utilities the progress is read. When in range start or update the VT. When out of range, clean up the VT (if any).
This logic is basically the same as with the scroll listener version.
In the future however, I expect the ScrollTimeline version to become more performant.
Once something like CustomEffect – in which you pass a callback function that receives the progress into the animation – becomes available, that could eventually replace trackProgress.
Or maybe we’ll get native Scroll/Gesture Driven View Transitions? Who knows? 😛
To summarize, the core of this all is to start a View Transition and hijack its animations. Either by pausing them and manually updating the currentTime, or by attaching them to a different type of timeline.
Again, kudos to @jaffathecake for leading the way here.
Add comment