fix: animation reload issue

[JoeyC-Dev]

Type of change

• Bug fix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other (please describe):

Checklist

• I have read the CONTRIBUTING document.
• I have checked to ensure that this Pull Request is not for personal changes.
• I have performed a self-review of my own code.
• My changes generate no new warnings.

Related Issue

Fix: #637 (comment)

Changes

1. Delay initialization of initCustomScrollbar() until after animations complete.
2. Remove staggered per-card animation-delay in PostPage.astro.
3. Add one‑time cleanup: stripOnloadAnimations() removes .onload-animation after the first animation ends.
4. Persist a session flag (sessionStorage.onLoadAnimationsDone) so later Swup navigations strip the class immediately.
5. Call stripOnloadAnimations() in Swup’s content:replace to handle newly injected DOM.

How To Test

Use DevTools to throttle traffic speed as 4G slow/3G to check if the page is still being reloaded.

Additional Notes

Root cause:
Swup swaps the page DOM without reloading assets. Elements that still have .onload-animation get reinserted on each content:replace, so the CSS keyframes restart and the navbar/post cards appear to “refresh” even though nothing is actually reloaded.

In conclusion:
Animation class is the trigger. Removing .onload-animation after the first run stops keyframes from restarting when Swup replaces the DOM. A session flag preserves this behavior across in‑app navigations for the rest of the session.

Others

I had a really rough morning. After 11 hours of trying to find a complete fix (I was only able to partially mitigate it), I still couldn’t solve the problem. For the next 5 hours, the coding AI kept telling me there was no fix and urged me to give up. I hadn’t slept for nearly 24 hours and felt overwhelmed - almost like the AI was pressuring me.

So let me summarize how this happens.
The reason why I said this was not related to swup is because I remove the following code, as the solution was to remove swup (and then nothing resolved):

fuwari/astro.config.mjs

Lines 36 to 49 in 6d39b0d

	swup({
	theme: false,
	animationClass: "transition-swup-", // see https://swup.js.org/options/#animationselector
	// the default value `transition-` cause transition delay
	// when the Tailwind class `transition-all` is used
	containers: ["main", "#toc"],
	smoothScrolling: true,
	cache: true,
	preload: true,
	accessibility: true,
	updateHead: true,
	updateBodyClass: false,
	globalInstance: true,
	}),

As of now, I asked GPT how this happens, and it told me the reason:

Removing that Swup config block won’t stop the re‑animation because the trigger is your CSS class and delays, not the Swup integration settings. Swup only replaces the DOM; when .onload-animation stays on newly inserted elements, the keyframes restart. Even if you change or remove Swup options, the class is still applied on each replace, so the animation still “reloads.”

Swup is working as designed. The fix is to strip the animation class after first run (and/or remove staggered delays), not to disable Swup or its config.

So, GPT seconds my initial conclusion, and I was partially right. But before I find out this, I was struggling on changing configuration like config.cache, config.preload for a long time (I totally have no idea what I am configuring as I don't have knowledge of this, so for a long time I thought this was my own problem), unless I find out none of these change anything and decide to disable the whole swup and find out the issue persists.

This is so despairing cuz I already spent hours on useless thing.

At the time, I decide to disable animation like what I mentioned in #637 (comment):

.onload-animation {
    opacity: 1;
    /* animation: 300ms fade-in-up; */
    /* animation-fill-mode: forwards; */
}

Since this started working, I began tracing the issue in Layout.astro and found that initCustomScrollbar() was causing the problem. More time passed.

But changing code of initCustomScrollbar() hit the dead end. I gave up, and the progress I made after then is as below:

setTimeout(() => {
	initCustomScrollbar();
	document.querySelectorAll('.onload-animation').forEach(el => {
		el.style.opacity = '1';	
		el.style.animation = 'none';
		el.style.transform = 'translateY(0)';
	});
}, 4000);

Summary from GPT:

It waits 4000 ms, initializes the custom scrollbar, then forces all .onload-animation elements to a final, non‑animated state by setting opacity: 1, disabling animation, and resetting transform to translateY(0). This prevents any further animation re‑triggering after that point.

Besides of this, I also remove staggered per-card animation-delay in PostPage.astro.

This solution will mitigate the issue: navbar no longer refresh but the post cards are now instant flashing. Whatever, already much better than fully reload.

But this is not full fix. This is mitigation. At the time I already gave up thinking anything and decide to hand in coding AI to let it made decision. And this is where the nightmare starts:
The coding AI tried some approaches, failed for another hour. And then told me to give up.
I changed to Copilot, and it asked me to use gsap.
I changed to whatever again, and it kept modifying "4000ms" to other values and asked me to build and test.
...

I was in high pressure because I kept being asking to give up and being given craps.

After watching the network tab and console log for a long time, the AI figures out that it can use sessionStorage to store a flag and then remove onload-animation class (reference).

Then the rest of the part is to refine the code and try to pass astro check as this is the correct approach.

During the whole debugging process, I built 79 times and lost patience partway through. Maybe the coding AI sensed something was off and told me to give up, that I will never know the true reason.

The next day I woke up and remembered what I’ve done before. I have just one comment:
I feel sorry for being a noob.

I’ve been using this blog theme for more than two years. I know I’m not a professional, but since no one fixed the issue, I had to do it myself.
Even when it was actively maintained in the past, no one implemented fundamental enhancements like OG images.

When someone not professional like me have to do the professional thing, it is really driving me crazy.
Vibe coding helps me to learn, so I decided to trying fixing issue. I know "vibe coding" itself may trigger some kind of group, but what can I do when seeing a bug is not being fixed for 2 years when I am using it? I tried to avoid, but there is no other way. I can't just waste another year and then fix it because may be there will be another "another year" after that "another year".

(Caption: last commit of initCustomScrollbar())

So, I decide to do it now. I did the test, and not always follow what coding AI gives. I tried to think what the AI is giving me. I already did the best I can do.

I'm not sure when the maintainers will check this repository again. Maybe you could add a "Sponsor" section and use the service like Ko-fi to accept funds, if that would help maintain the project. Because no one knows when a noob like me have to deal with such bugs, what consequences (bugs) they can introduce.

[vercel]

@JoeyC-Dev is attempting to deploy a commit to the zephyirdgmailcom's projects Team on Vercel.

A member of the Team first needs to authorize it.