Hover
Concept
The appearance an element takes while a pointer sits over it, announcing in advance that the thing can be pressed.
Why it exists
Which things on a screen are pressable is not always readable from their appearance. Blue underlined text reads as a link by long convention, but plenty of black text and gray boxes respond to a press too.
Pagedeck's document list worked that way. Titles were black text and the entire row was the press target, yet users aimed carefully at the title characters. Nothing told them that pressing the empty part of the row would open the document either. Noa made the row background shift to a light gray on pointer entry and that settled it — people work out for themselves that the area changing color is the area that responds.
Hover is that: changing appearance only while the pointer is over an element, to say in advance that it reacts. The default state is how something looks with no interaction at all, and hover is the first response layered on top of it.
How it works
The style switches when the pointer enters the element and reverts when it leaves. Five things get decided.
- What changes — one or two of background color, text color, border, and shadow. The cursor turning into a hand is part of the same signal, so it goes along with them.
- How much it changes — only enough to notice. One step darker on the background is typical; change the color outright and the screen flickers while someone scans a list.
- Transition timing — somewhere between 100 and 150 milliseconds. Turning it on instantly and reverting slightly more slowly makes a pointer passing across less distracting.
- The area — match the region that changes color to the region that actually responds. A row that lights up while only the title is clickable is a screen that lies, and the user learns to stop trusting the highlight.
- Touch screens — a finger has no hovering. Anything conveyed only through hover disappears entirely on mobile, so explanations and menus don't live there alone.
How it sounds at work
"There's no hover here, so I can't tell whether it's pressable."
The state that announces a reaction is missing.
"The hover covers the whole row but only the title actually responds."
What's shown and what's clickable have come apart.
"Put that explanation only in a hover and nobody on mobile will ever see it."
This state doesn't exist on touch screens.
When Noa built the row hover for the document list, the background went one step darker and the transition was set to 120 milliseconds. Theo widened the clickable region to the whole row so it matched the area changing color. Mis-presses in the list dropped, and the same rule carried over to tables and card lists.
Easily confused with
| Term | When it appears | How it differs |
|---|---|---|
| Active | While being pressed | The difference between before a press and during one. Hover is a preview and active is confirmation, so giving them the same appearance leaves nobody able to tell a press registered |
| Focus | When selected by keyboard | It occurs without a mouse, so hover can't stand in for it. Build the two as one and a keyboard-only user can't tell where they currently are |
Where to go next
- UI state
see which set this state belongs to
- Default state
see the base that hover layers onto
Last updated 2026-09-16