18 Tailwind CSS Product Cards

Demo 01 and Demo 05 hide the action until hover using a group parent and opacity-0 group-hover:opacity-100 on the child. That reads well with a pointer, but hover has no equivalent on a touchscreen — the button is invisible, and the tap that would reveal it is the same tap that should add to cart. Two fixes: gate the reveal behind @media (hover: hover) so touch devices show the control at rest, or keep it always visible on small breakpoints and only hide-until-hover from md: up. Never leave a purchase action reachable by hover alone — a customer on a phone can't buy what they can't see. The same rule applies to the slide-up panel in Demo 05: its content must stay operable without a pointer, so promote it to a persistent state below your hover breakpoint.

Demo 02 flips inside a shared 3D context. The outer wrapper sets perspective so the rotation has depth, an inner element gets transform-3d (Tailwind v4's first-class utility for transform-style: preserve-3d), and the two faces are absolutely stacked with backface-hidden. The back starts pre-rotated rotate-y-180; on hover the inner rotates 180deg so the back swings forward while the front turns away. The ghosting bug is forgetting backface-hidden — both faces paint at once, so you see a mirrored copy of the front bleeding through the spec text. The second common bug is putting overflow-hidden on the perspective parent, which clips the card mid-rotation. Keep perspective on an untrimmed ancestor and the preserve-3d plus backface utilities on the rotating layer only.

Demo 04 needs no library. A pointer handler on the card reads the cursor's position within the element's bounds and writes a few CSS custom properties — the rotation on X and Y plus the glare's coordinates. Every visual (rotate-x, rotate-y, the highlight) is bound to those variables through Tailwind's arbitrary-value syntax, so the browser handles compositing and JavaScript only sets numbers. Reset the properties on pointerleave or the card stays frozen at its last angle. Two cautions: throttle the handler with requestAnimationFrame so you write once per frame rather than on every mousemove, and honour motion preferences — wrap the effect so prefers-reduced-motion: reduce disables the tilt entirely. A card that lurches under the pointer is exactly the vestibular trigger that setting exists to prevent, so this isn't optional polish.

Demo 11 is a horizontal cart-row card that reshapes based on its own width, not the viewport's. You mark the wrapper as a query container (@container) and the child switches from stacked to side-by-side with container variants like @md:flex-row. This is the right tool when the same card sits in a wide main column on one page and a narrow sidebar on another — a viewport media query can't tell those apart because the window width is identical, only the container's width differs. The frequent mistake is styling with @md: but never declaring the container, so nothing responds; the variant needs an ancestor carrying the container declaration. Also remember the query measures the container's own box, so padding on that element counts — if a breakpoint fires slightly early, the container is wider than its visible content.

Demo 12 is the catalog wrapper, not a single card. Its columns are defined once with repeat(auto-fit, minmax(200px, 1fr)), so the browser fits as many columns of at least 200px as the row allows and stretches them to share the leftover space — no per-breakpoint column counts. The classic bug is sideways overflow on narrow screens: minmax(200px, 1fr) refuses to go below 200px, so on a 320px phone with grid gap and padding the track exceeds the viewport and scrolls horizontally. Fix it by lowering the floor with minmax(min(200px, 100%), 1fr), letting a lone column shrink under 200px when that's all the room there is. Use auto-fit to stretch a short final row to full width, or auto-fill if you'd rather keep empty phantom tracks and leave the cards at their natural size.

Demos 14 and 18 change state without JavaScript by leaning on hidden radio inputs and the peer relationship. Each colourway swatch is a <label> tied to a visually-hidden <input type='radio'>; checking one retints the card through peer-checked: utilities on later siblings. Because it's a real radio group, arrow keys move between options and only one stays selected, for free. Two things to get right: the inputs must share a name so they're mutually exclusive, and you must hide them with a screen-reader-safe technique — an sr-only style, never display:none, which drops them from the tab order and the accessibility tree. Keep a visible focus ring on the label's checked and focused state so keyboard users can see where they are: the swatch is the control, so it must show focus.

Demo 07's frosted look is mostly core utilities — backdrop-blur-lg plus a translucent bg-white/10 and a hairline border-white/20. The catch is that backdrop-filter blurs whatever sits behind the element, so over a flat solid page there's nothing to blur and the card just looks like a semi-transparent panel; glass only reads over an image or gradient. Demo 09's conic border spins a conic-gradient behind the card and reveals it by insetting an opaque inner layer, with a blurred duplicate beneath for the glow. Yes, watch performance: an always-on animated conic gradient repaints continuously, so trigger the spin on hover rather than at rest and gate it behind prefers-reduced-motion. Both effects also need a fallback colour where backdrop-filter is unsupported, or the text loses its background entirely.

The interactive controls in Demos 16 and 17 must be real elements, not styled <div>s. The stepper's plus and minus are each a <button type='button'> so they're focusable and fire on Enter and Space; give each an aria-label like 'Increase quantity', because a bare +/- glyph means nothing to a screen reader, and mirror the count into an aria-live region so the change is announced. The favourite heart in Demo 17 is a toggle, so it needs aria-pressed reflecting its on/off state rather than swapping only the icon colour — colour alone isn't perceivable to everyone. When should you skip these richer cards? If you have no real inventory or pricing yet: a card built around a specific stepper, size grid or beds/baths feature row looks broken stuffed with placeholder text, so reach for a simpler layout until the content exists.