Query Loop: Add animation when navigating with "enhanced pagination" enabled #54746
Conversation
|
Size Change: +21.2 kB (+1%) Total Size: 1.64 MB
ℹ️ View Unchanged
|
DAreRodz
added
[Type] Enhancement
|
Flaky tests detected in 40ad702. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6407222363
|
|
I'm not convinced yet about either of these. I think we need to review it more carefully. |
@luisherranz, what exactly doesn't convince you?
A little more feedback would be great. 😄 PS: I'm turning this back to draft, just in case. |
|
I'm not convinced about the API (although that's not critical because it's not public), and the animation doesn't feel right. It's not your fault, it's just that I'm not sure whether it adds value to the navigation or not. My inclination is that it doesn't and needs more experimentation. The smooth scroll is nicer, but it doesn't work in Safari and Firefox (although it should?) so that needs more experimentation. In general, it feels a bit rushed to fit all this in today's Beta 1. |
TBH, I had the same feeling. 🙁 I think it's because the smooth scroll happens simultaneously, so you can barely notice the animation. When there's no scroll, it feels a bit nicer.
That's bad. I wasn't aware, but it looks like |
|
Thank you for taking a stab at this! I would echo Luis, in a direct comparison between these two, I'd prefer no animation, but I think we can tweak things so it works. Reading into the term "kansei", I'm sensing that captured in that aesthetic sensibility is a need to think about the fuller flow, not just the particular properties of the animation. In that sense, it is good to think through said flow:
If that is the fuller flow, to realize a good experience we could potentially look at every step of the way:
Pursuant to what's possible, we might try to string all those properties together in one of two ways: Slow version
Fast version If the slow version above ends up feeling annoying, try the same recipe, but speed up every value so it's faster than what's demoed in the video on this PR. Virtually instant, but just considered (as per the recipe), and eased instead. Hope that helps! |
|
Nice try. I agree it isn't ideal. I do wonder (and was the intent when mentioned) if it's simply a slight fade in between pagination, no scrolling up. |
|
Thanks for the feedback, @jasmussen and @pablohoneyhoney. 🙏
I want to try this first, as it seems simpler to develop. Just to clarify―when you say no scrolling up, you mean disabling the smooth behavior rather than not scrolling at all, is that right? |
I've been discussing it with @luisherranz, and we are afraid that removing the scrolling will break the a11y. In case, I've asked @DAreRodz to do a pair programming session with a designer so they can try different approaches synchronously and hopefully land a solution quickly :) |
|
To understand, focus is moved from the "Oldest" to the top of the query block, just like it would if it was a full page refresh. Correct? To that end, I think Pablo's point that the query itself could have a simple fade in, and just immediately jump (no animation on scrolling) depending on the browsers focus behavior. If I'm not wrong, then in cases where the whole query is visible, there would be no scrolling. |
Yes. Well, it's not exactly as a full page refresh because, as you say, the focus is moved to the first clickable element of the Query block instead of the first clickable element of the page (which is a better experience in terms of accessibility). So the focus goes from the link you just clicked to the first clickable element of the Query block.
Exactly. Scrolling is 100% handled by the browser. Each browser does a slightly different thing, but in general they ensure that the new focused element (the first clickable element of the Query block) is visible. |
|
This is the latest feedback I received from @jasmussen:
Given that, I removed any motion from both the scrolling behavior and the fade-out/in animations. The scroll position changes when the fade-in animation starts, so it feels like the Query Loop items are appearing already in their place. Also, now that there is no motion at all, I got rid of any code related to I think it's better now. 🙂
cc: @luisherranz @Poliuk |
|
Agreed, that is a better experience. In general if an animation doesn't feel right, it's usually best to omit it. It's a bit frustrating how the three browsers entirely diverge in their handling of focus-scroll, but I'm assuming this is something best left entirely untouched, correct? What happens to the fade if the next items in the query need to load? |
The fade-out animation is triggered when the data is ready before updating the HTML. The new HTML is updated once the fade-out has finished, and the fade-in animation starts right after. So, in answer to your question, the transition should only be visible once the following items are ready. In the meantime, you can see the loading top bar progressing, so you still have feedback that the browser is waiting for the following items. |
|
After more thinking, I'm opposed to this change. It doesn't make sense to me to introduce imperative APIs to control the So, in my opinion, we should keep investigating how to control the View Transitions API using directives, and how to grant that control to the themes so they can override the block defaults (View Transitions discussion). |
luisherranz
removed
the
[Feature] Interactivity API
|
I'm setting this PR to draft again, as we won't include these changes for now. |
|
Changing the type of the PR to "experimental" and closing it. We can revisit these changes in the future if needed. 🙂 |
DAreRodz
added
[Type] Experimental
What?
This PR adds a subtle animation when visiting different pages of a Query Loop with "enhanced pagination" enabled. It also adds a smooth scroll behavior for the navigation.
When
reduced-motionis preferred, the animations and the smooth scroll are turned off automatically.Will close #54060.
Why?
To make the transition a bit more kansei, as mentioned in #53812 (comment).
How?
For the animations, I had to add a new option to
navigate()namedbeforeRender. It's a callback that runs right before we call Preact's render to update the HTML. The callback can be asynchronous, and this PR uses it to animate the current Post Template block before it's updated.For the scroll behavior, I'm changing the value of the
scroll-behaviorCSS property on thedocument.scrollingElementtosmoothright before callingelement.focus()and restoring its previous value right after.Testing Instructions
Screenshots or screencast
reduced-motionreduced-motionScreen.Recording.2023-09-25.at.14.10.45.mov
Screen.Recording.2023-09-25.at.14.09.23.mov