Views UI action buttons create janky layout shift on page load

mherchel → changed the visibility of the branch 3441124-views-ui-action to hidden.

mherchel → changed the visibility of the branch 3441124-views-ui-action to hidden.

mherchel → changed the visibility of the branch 3441124-views-ui-action to hidden.

mherchel → changed the visibility of the branch 3441124-views-ui-action to active.

MR should be ready to go! Here's a video (taken with throttling set to "Fast 3g") for comparison.

can confirm seeing the jump mentioned by @mherchel.

CSS changes stop the jump.

How does it recover if the js crashes or doesn't finish downloading?

Thats a good question :)

When I intentionally break that JS, the buttons will no longer show, which is a regression.

Setting back to NW. I'm pretty confident I can find a way around this. Plus it might make sense to move this out of Claro and into the Views CSS, as the JS that moves it around lives there.

I think I found a really good workaround for this.

1. Checks if JS is disabled. If it is, nothing changes
2. Hide any of the buttons that are not in their final destination (as placed by JS).
3. The buttons are hidden by an animation that sets display: none in its initial keyframe, and the animation is set to fill backwards.
4. The animation is delayed by 5s, and when it runs (which is set to 0.1s), it will remove the display: none.

So the net result is that the unstyled buttons will be invisible for 5s max. So, if JS is broken they'll pop in at that time.

Note that I placed this in both the Views UI module's CSS, and Claro's CSS (which overrides the Views UI CSS)

ohh clever, i like that. Don't hesitate to make a class or something out of it. All the MR doing the same thing will need it I think

Nice!

So should this be turned into a generic class to apply? Or good to mark?

should this be turned into a generic class to ap

I say no. If native CSS had the equivalent of Sass mixins, it'd be easy to do, but that's down the horizon. The current selector that we're using is .views-tabs__action-list-button:not(.views-tabs--secondary *), which is somewhat complex, and would be more of a pain in the butt to replicate in templates/preprocess.

Testing the new solution I'm still seeing the issue is resolved. May be bookmarking this solution.

Applied MR, changes are looking Fixed now

So given #14 and #17 (and that Théo is a frontend framework manager), I think there should at least be a middle ground here where we at least document this somewhere on d.o in a way that will be helpful to the other places where it needs to be fixed, or create a followup issue to make a core addition that would also address @mherchel's concern. Thanks everyone!

I'm willing to create a class or do whatever it takes to get this done, but I do think doing so will be premature optimization at this point. I'm not 100% positive I know a place where we'd be able to re-use it.

I started a slack thread in the #contribute channel at https://drupal.slack.com/archives/C1BMUQ9U6/p1714158882541689

📌 Investigate possibility of creating API, CSS class, reusable animation to help eliminate page jank Active addresses my concern. Thanks!

Restoring previous status, although I still think it's best if a FEFM reviews this one for commit.

Just pushed some changes with the comments.

As far as creating a CSS Variable, I'd like to push that over to 📌 Investigate possibility of creating API, CSS class, reusable animation to help eliminate page jank Active . There we can also abstract the @keyframes animation. But my thought is that we'd probably want to create a new library, and we'd need to decide where that lives (within Claro, system, etc)... which to me seems out of scope of what we're doing here.

Let me know if that's alright. If not, I can create the variable and put it in the views_ui.admin.css file.

all good with me. I'm ok with the variable being in the follow-up, the keyframe stuff was going to be my next question :p let's do that in the other issue.

Thanks! Putting back to RTBC per #18 since all that changed were code comments.

Committed 299f4c8 and pushed to 11.x. Thanks!

I think that solution is pretty clever, could be good to have in a blog post somewhere :)

nod_ → closed merge request !7506

could be good to have in a blog post somewhere :)

Thanks! Yeah, I have one somewhat thought out in my head about reducing jank, and this would be a part of it. Just need to find time!

Thanks @nod_ and @mherchel!

Automatically closed - issue fixed for 2 weeks with no activity.