Skeleton-to-Content Crossfade — Overlapping Fade Loading Transition

Most skeleton-to-content transitions are actually a hard swap: the placeholder disappears, then the real content appears, often with a visible flash or layout pop between the two states. A true crossfade is different — the outgoing skeleton and the incoming content fade simultaneously, briefly overlapping, so there is never a moment where neither is visible or where the swap reads as instantaneous. This snippet builds exactly that timing in plain HTML, CSS, and a small amount of JavaScript, and the crossfade's overlap is the entire point of the pattern — not a byproduct of two elements happening to occupy the same space.

Two full layers, stacked, both always present

Rather than removing the skeleton from the DOM when content is ready, both .cf-skeleton and .cf-content are absolutely positioned to fill the same card (position: absolute; inset: 0), stacked directly on top of each other. This is what makes a true overlap possible: since both layers occupy identical space at all times, transitioning one's opacity down while the other's opacity rises simultaneously produces a genuine cross-dissolve, the way a film crossfade works, rather than a layout-driven swap where one element's removal shifts the other into view.

One class flip drives both transitions

A single is-loaded class on the parent .cf-card controls both layers via CSS: .cf-skeleton opacity goes to 0 and .cf-content opacity goes to 1 in the same rule change, both using an identical transition: opacity .4s ease. Because one class toggle drives both transitions with matching durations and easing, the fade-out and fade-in are mathematically synchronized — at the 200ms mark, the skeleton is at 50% opacity and the content is simultaneously at 50% opacity, which is the actual definition of a crossfade rather than two independently-timed animations that happen to look similar.

Why the timing needs a frame, not just a class toggle

loadIn() first removes is-loaded to reset to the skeleton state, then waits for a requestAnimationFrame before scheduling the switch to loaded. Toggling classes in the same synchronous tick can let the browser coalesce the "before" and "after" states into a single paint, skipping the transition entirely — waiting a frame guarantees the reset state is actually committed and painted before the transition to loaded begins, so the crossfade reliably plays every time, not just occasionally.

Pointer-events follow opacity, not the other way around

Both layers toggle pointer-events alongside opacity — the invisible layer becomes unclickable and the visible one becomes interactive — so during the brief overlap window neither a lingering skeleton nor an about-to-appear content card can intercept clicks meant for the other.

Distinct from a plain skeleton or a hard swap

A standard skeleton loader never demonstrates the transition to real content at all — it only shows the placeholder state. And a naive swap (display: none on one, display: block on the other) has zero overlap by construction, since display can't be transitioned. This snippet is specifically about the overlap: tune the shared .4s duration, or offset the two layers' transition-delay slightly so the fade-in trails the fade-out by a beat for an even softer dissolve. Pair it with a skeleton card grid for a whole grid of independently-timed crossfading cards.