Pointer depth on the cards, and scroll reveals where the glass allows it

[PArns]

Two things: pointer depth on every card, and a scroll reveal on the sections that can take one.

Pointer depth on the cards

The photo drifts a few pixels against the pointer while the frosted panels hold still, and a soft highlight follows the pointer across the card. The drift is the idea — moving the picture while the glass stays put is what makes the panels read as floating above it rather than printed on it, and it is the one part CSS cannot do, because it needs the pointer's position.

CardPointerFx is mounted once and delegates: one pointerover listener on the document finds the card with closest(), and the per-frame work is bound only while a card is actually hovered. A grid of twenty cards costs the same as one. It skips itself entirely for reduced motion and for coarse pointers.

The drift goes on the <img> inside CardPhotoFrame, never on the card. The card carries the two backdrop-filter panels, and a transform on it would make it a backdrop root for as long as the pointer was inside — the glass would go flat exactly while somebody is looking at it.

Worth recording, because I went in expecting the opposite: Tailwind's existing hover:-translate-y-1 on the card is safe. v4 compiles it to the standalone translate property, and Chromium does not treat that as a backdrop root. Measured through a hover, the panel's backdrop detail holds at 26.96 → 26.84.

The highlight has no blend mode, and that was the whole performance story

mix-blend-mode: overlay looked richer and cost the entire feature. Sweeping one card, median frame time:

	1× CPU	4× CPU
drift + highlight, blended	43.6 ms	44.3 ms
drift + highlight, no blend	38.3 ms	35.4 ms
drift only	38.9 ms	34.0 ms
neither (baseline)	39.4 ms	36.2 ms

Without it the whole effect sits inside the baseline's noise. A blended layer has to re-read what it sits on — here, two frosted panels — every frame; a plain translucent gradient just composites.

Two notes for whoever tunes this next:

• Measure from inside the page. Driving the pointer with Playwright's mouse.move puts a CDP round trip between frames. It reported a 20 ms regression that does not exist, and I nearly cut the feature over it before re-measuring with synthetic events dispatched in a rAF loop.
• Caching the card's rect instead of reading it per frame turned out not to matter here. It stays in anyway — reading layout inside a rAF that then writes styles is a trap regardless of whether this particular page notices.

Section reveals

.pk-reveal is a scroll-driven CSS animation (animation-timeline: view()), deliberately not the existing <Reveal> component. <Reveal> renders opacity-0 and needs an IntersectionObserver to bring it back, so with JavaScript blocked its content never appears — the one thing this codebase does not do with content. A view timeline degrades the other way: no support means the section simply shows, unanimated. It fills backwards, so nothing lingers afterwards.

It only goes on sections with no glass in them. During the entry range the transform is real, so any backdrop-filter underneath flattens for the length of the reveal. That rules out the ML-stats and live-activity sections — both nest GlassCards — and card grids, which get the pointer effects instead. My first pass had all four sections wired; a browser check found 11 backdrop-filter elements inside a reveal and two of them came back out.

Checks

• pnpm build — green; /[locale] still reports 1h in the revalidate column
• pnpm release:check — lint, format, translations, client-message namespaces
• Verified in the browser: the card never takes a transform, the panel keeps blur(16px) through a hover, the photo drifts ±4 px per axis and returns, zero backdrop-filter elements inside a reveal, and revealed sections show transform: none / opacity: 1 once past the range

🤖 Generated with Claude Code

https://claude.ai/code/session_012y3NUKjqx4ZxrCseyCDXeQ

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
park.fan	Ready	Preview	Aug 7, 2026 9:32am