In CSS, how do the hover, any-hover, pointer and any-pointer media features differ, and how would you use them to adapt an interface to touch versus mouse input?

## Capability, not device class The long-standing bad habit in responsive CSS is inferring input from dimensions: narrow viewport, therefore touch, therefore no hover and bigger buttons. Both halves of that inference are wrong in common cases. A desktop browser window dragged to phone width still has a mouse; a 12-inch tablet has an enormous viewport and no mouse at all; a touchscreen laptop has both. The `hover` and `pointer` interaction media features exist so you can ask about the input directly. ## The four features **`pointer`** describes the accuracy of the *primary* pointing device: - `none` — no pointing device at all (a TV with only a remote, a keyboard-only kiosk). - `coarse` — present but imprecise, with a large contact area: a fingertip on a touchscreen. - `fine` — precise: a mouse, a trackpad, a stylus. **`hover`** describes whether that primary device can hover over an element without activating it: `hover` or `none`. Touch cannot — the first contact is already a tap. **`any-pointer`** and **`any-hover`** ask the same questions of *every* available input mechanism, matching if at least one qualifies. `any-pointer` can therefore match several values at once conceptually: on a touchscreen laptop both `(any-pointer: fine)` and `(any-pointer: coarse)` match. Typical devices resolve like this: | Device | `pointer` | `hover` | `any-pointer: coarse` | |---|---|---|---| | Phone / tablet | `coarse` | `none` | matches | | Desktop with mouse | `fine` | `hover` | no | | Touchscreen laptop | `fine` | `hover` | matches | | TV with a remote | `none` | `none` | no | ## Gating hover-only affordances The canonical use is anything that only reveals itself on hover — a row's action buttons, a card's overlay caption, a tooltip: ```css .row .actions { opacity: 1; } @media (hover: hover) { .row .actions { opacity: 0; transition: opacity 150ms; } .row:hover .actions, .row:focus-within .actions { opacity: 1; } } ``` Note the shape: the *accessible* state is the default, and hiding is the enhancement applied only where hovering is possible. Written the other way round — hide by default, reveal inside a `(hover: none)` block — a browser that doesn't match either branch leaves the controls invisible forever. Fail toward visible. ## Sizing for a coarse pointer The second use is hit-target size. A fingertip's contact patch is roughly 8–10mm, which is why touch guidance lands around a 44px minimum target. Rather than tying that to a breakpoint, tie it to the pointer: ```css @media (pointer: coarse) { .icon-button { min-block-size: 2.75rem; min-inline-size: 2.75rem; } } ``` This is exactly the case where viewport width misleads: the tablet that most needs large targets has the widest viewport in the room. ## Hybrid devices and the `any-` variants Hybrids are where naive queries break. A touchscreen laptop reports `pointer: fine` and `hover: hover` because the trackpad is primary — so a `(pointer: coarse)` block never fires even though the user may be tapping the screen. Two defensible policies: - **Keep hover enhancements on `hover: hover`.** Hybrid users get them, and because the affordance is an enhancement over an already-usable default, touching the same screen still works. - **Use `any-pointer: coarse` for anything about safety or reach** — destructive buttons, drag handles, close targets — so a device that *can* be touched gets forgiving targets regardless of which input is primary. What you should not do is treat these queries as a device-detection oracle. The user can plug in a mouse mid-session, or pick up a detachable tablet's keyboard; browsers do re-evaluate when the primary mechanism changes, but the transition is not something to build critical behaviour on. Design so that either input works and the query only tunes the experience. ## The sticky-hover trap A related production issue: on touch, tapping an element that has a `:hover` rule frequently leaves the hover style applied until the user taps elsewhere, because the browser synthesises a hover state around the tap. Buttons that turn a different colour on hover appear stuck in that colour after being pressed. Wrapping hover styling in `@media (hover: hover)` removes the problem at the source rather than patching it with script. ## What these features do not tell you They do not report the operating system, the browser, the screen size, or whether a keyboard is present. Keyboard accessibility is orthogonal and must be handled with `:focus-visible` regardless of what the pointer queries say — a hover-revealed control that is not also focus-revealed is inaccessible on *every* device, which is why the example above pairs `:hover` with `:focus-within`.