{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreihnhamivodvkfxcjfjocevlhnneps3lhuskpdxedmoblt6w2v5g2y",
"uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3moiu7htfces2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreifescyyvs3gkh6lwqa4jt44brcxzr7m3n55uk3c5yzftvy35gg7fa"
},
"mimeType": "image/webp",
"size": 79894
},
"path": "/aanshik_sharma_26dd97ab33/the-css-media-query-that-changed-how-i-approach-responsive-desig-c1a",
"publishedAt": "2026-06-17T17:30:00.000Z",
"site": "https://dev.to",
"tags": [
"css",
"design",
"frontend",
"webdev",
"@media"
],
"textContent": "I was working on the responsiveness of my portfolio website when I discovered a CSS media query that changed how I think about responsive design.\n\nI initially thought I needed a way to detect whether the website was being viewed on a mobile device or tablet.\n\nI did that by checking if the height of the document body was greater than its width hoping it would be a reliable solution.\n\n\n\n const isVertical= document.body.clientHeight > document.body.clientWidth;\n\n\nI realized that I was checking the device’s portrait orientation instead of checking for the device type.\n\nWhile researching the issue, I encountered this CSS media query that checks if the user’s **primary input device can conveniently hover over DOM elements.**\n\n\n\n @media (hover: hover) {\n /* styles for devices that support hover */\n }\n\n\nTailwind also supports this through arbitrary variants\n\n\n\n <Card className=\"[@media(hover:hover)]:bg-teal-800\" />\n\n\nDevices that match\n\n * Desktops with mouse\n * Laptops with trackpad\n * Most devices with a mouse pointer\n\n\n\nDevices that do not match\n\n * Touch-only phones\n * Touch-only tablets\n\n\n\nHowever, devices with an attached mouse or trackpad may behave differently\n\nFor example,\n\n\n\n .button{\n opacity: 1;\n }\n\n @media (hover: hover) {\n .button{\n opacity: 0;\n }\n\n .card:hover .button{\n opacity: 1;\n }\n }\n\n\nOn mobile devices,\n\n * The button is always visible\n * `:hover` rules are ignored\n\n\n\nOn a laptop,\n\n * The button starts hidden\n * Appears when the card is hovered\n\n\n\nThis can also be used the other way around to explicitly check if the device is **unable to hover** over DOM elements.\n\n\n\n @media (hover: none) {\n /* styles for devices that do not support hover */\n }\n\n\nor in tailwind as `[@media(hover:none)]:bg-teal-800`\n\nAnother useful media feature is `@media (pointer: fine)`, which checks pointer precision of the primary pointing device. A table below describes how both the queries respond with primary input devices.\n\nDevice | Hover | Pointer\n---|---|---\nMouse | hover | fine\nTrackpad | hover | fine\nFinger touch | none | coarse\nStylus | usually hover; could be none depending on the device | fine\n\nPointer characteristics are implementation-dependent and may vary across browsers and operating systems.\n\nSince we have already discussed `hover` and `pointer` there are two important properties that I believe must be mentioned.\n\n\n\n @media (any-hover: hover) {\n /* styles */\n }\n\n @media (any-pointer: fine) {\n /* styles */\n }\n\n\nThese differ from\n\n\n\n hover\n pointer\n\n\nbecause they consider **all available inputs** rather than just the primary one.\n\nFor example,\n\n * Tablet + mouse attached\n\n\n\nmight report\n\n\n\n hover: none\n\n\nbut\n\n\n\n any-hover: hover\n\n\nThis was a small discovery, but it changed the way I approach responsive design. If you're building interactions that depend on hover or pointer precision, these media queries are worth keeping in mind.",
"title": "The CSS Media Query That Changed How I Approach Responsive Desig"
}