Card hover lift check: when every card floats up

Why the lift became a tell

Utility CSS frameworks make a hover lift one short class, and component examples apply it to every card, so models trained on them do the same. The result is a grid of feature cards, testimonials and pricing plans that all bob upwards as the pointer crosses them. Movement draws the eye, so movement on everything draws it nowhere. It also misleads: a card that rises looks pressable, and many of these cards aren't links at all. And on a phone, where there's no hover, the effect does nothing except occasionally stick after a tap. The hover effects guide covers good hover design more broadly.

What the card hover lift check matches

The Critic reads the page's stylesheet for a :hover rule that contains translateY(-, that is, a transform that moves the element up. A few consequences follow from matching the code rather than the screen:

It isn't only cards. A button or a link that rises on hover fails just the same; the label says cards because that's where the habit is commonest.
One is enough. Despite its wording about cards all lifting, a single upward hover rule anywhere on the page fails it.
Other ways of moving up pass. translate(0, -4px), translate3d() or the separate translate property aren't matched, and neither is a rule written for a child of the hovered element.
Downward movement passes. Moving an element down or sideways on hover isn't what the check looks for.

So treat a pass as "no standard lift found", not as proof the page has no floating cards.

Hover states that say something

A good hover answers one question: what will happen if I click? Anticode's design systems each use effects tied to what the element does:

Hover effects on design-engine pages
Element	What happens on hover
Buttons	A slight brightening of the action colour, quickly, on a tuned curve
Luxury's outlined buttons	They fill with the action colour
Brutalist's buttons	They press into the page: two pixels down and right, with a smaller shadow
Product cards in a shop	The photo zooms very slightly inside its frame; the card itself stays put
Navigation links	The text darkens from the muted colour to full text colour
Links in a page index	A small arrow slides a few pixels to the right and takes the action colour

Feature cards, testimonials and pricing plans don't move at all, because they're not links. The only element whose frame changes is one you can press, and the change describes the action: forward, into, brighter.

Fixing a failure

Find the hover rule with the upward translate, and ask whether the element is clickable.
If it isn't, remove the hover effect altogether.
If it is, replace the lift with a change that suits it: a colour or underline change for links, a fill or press for buttons, a gentle zoom of the image inside a fixed frame for product cards.
Keep any hover change quick, around 150 milliseconds, and on a tuned curve; the default ease check covers why.
Make sure the same state appears on keyboard focus, so people who don't use a mouse get the same feedback.

Avoid replacing the lift with a fade. A hover that only changes opacity is flagged by its own check, the opacity hover check, because it makes the element look disabled.

Limits

Reported, not enforced. The design gate doesn't include this check.
No judgement of context. A deliberate lift on a single draggable tile fails the same as twelve bobbing cards.
Design-engine pages already pass. The code editor doesn't keep CSS changes beyond colour tokens, so a failure is unlikely on these pages; the check matters most as a rule for your own code and exported projects.

Questions people ask

Should cards move up on hover?

Rarely. Only clickable things need a hover state, and for a card the image zooming inside its frame, or a clear link style, is calmer and more honest.

Does a button that rises on hover fail?

Yes. The check matches any hover rule with an upward translateY, not just cards.

Will it stop me publishing?

No. It's shown in the Report tab only.