Modern CSS Layouts & Micro-InteractionsProduction-focused CSS patterns and architecture

Button Press and States

Hover says "this is interactive"; the press says "I heard you". A button that does not visibly react to being pressed feels broken on touch screens, where there is no hover to prepare the user and the finger covers most of the target. The fix is small — a slight depression, a darker fill — but the details decide whether it feels crisp or mushy: how fast the press lands, how long the release takes, whether it works for taps and keyboard presses as well as mouse clicks, and how the disabled state differs from all of these. This page builds a complete button state set with CSS alone. It belongs to Hover & Focus State Design in the CSS-Only Micro-Interactions & Animations guide.

The five states of a button

A robust button has five visual states, and each has a different job. Rest establishes the button. Hover confirms that a pointer is over it. Focus-visible shows keyboard users where they are. Active acknowledges the press. Disabled says the action is unavailable. The active state is the shortest-lived, usually shown for well under a second, and it overlaps with the others: a mouse press is hovered and active at once, a Space-key press is focused and active.

Five states, five jobs Five buttons in a row. Rest: solid blue with a small shadow. Hover: a lighter fill. Focus-visible: rest appearance plus a two-pixel outline offset from the edge. Active: darker, pushed down two pixels, shadow nearly gone. Disabled: muted grey with no shadow. One button, five states Save Save Save Save Save rest hover: lighter focus: outline active: press disabled: flat Active overlaps hover (mouse) and focus (Space key); it must read on top of either.

The complete implementation

Press the buttons in the demo with a mouse, a finger or the Space key. The press lands almost instantly; the release eases back.

Live demoPress, release, focus and disabled states
Press and hold a button, then release. The press lands in 60ms and the release eases back over 200ms. Tab to a button and hold Space to see the keyboard press. 
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Button press states</title>
<style>
  body { font: 16px/1.5 system-ui, sans-serif; margin: 2rem; display: flex; gap: 1rem; flex-wrap: wrap; }

  .btn {
    --btn-bg: #2563eb;
    font: inherit;
    font-weight: 600;
    padding: 0.625rem 1.25rem;
    min-block-size: 44px;
    border: 0;
    border-radius: 8px;
    color: #fff;
    background: var(--btn-bg);
    box-shadow: 0 2px 0 #1e40af, 0 3px 6px rgb(0 0 0 / 0.15);
    cursor: pointer;
    /* Release: a relaxed return. */
    transition:
      translate 200ms cubic-bezier(0.2, 0, 0, 1),
      box-shadow 200ms cubic-bezier(0.2, 0, 0, 1),
      background-color 150ms ease-out;
  }

  @media (hover: hover) {
    .btn:hover { --btn-bg: #3b82f6; }
  }

  .btn:focus-visible {
    outline: 2px solid #1d4ed8;
    outline-offset: 3px;
  }

  .btn:active {
    --btn-bg: #1d4ed8;
    translate: 0 2px;
    box-shadow: 0 0 0 #1e40af, 0 1px 2px rgb(0 0 0 / 0.2);
    /* Press: nearly instant. */
    transition-duration: 60ms;
  }

  .btn:disabled {
    --btn-bg: #94a3b8;
    color: #f1f5f9;
    box-shadow: none;
    translate: none;
    cursor: not-allowed;
  }

  @media (prefers-reduced-motion: reduce) {
    .btn:active { translate: none; }   /* keep the colour change, drop the movement */
  }
</style>
</head>
<body>
  <button class="btn" type="button">Save</button>
  <button class="btn" type="button">Publish</button>
  <button class="btn" type="button" disabled>Delete</button>
</body>
</html>

The button translates down by exactly the height of its hard bottom shadow (2px) while the shadow collapses to zero. That pairing is what makes it read as a physical key being pushed into the surface rather than a box sliding downwards. Hover is confined to @media (hover: hover) so touch devices, which emulate hover on tap, do not show a hover colour that then sticks after the finger lifts.

The key technique: asymmetric timing

The transition declared on .btn governs the return to rest; the one on .btn:active governs the press. CSS always uses the transition values of the state being entered, so the press (entering :active) runs in 60ms and the release (leaving it) in 200ms. That asymmetry matches physical expectations: a key goes down as fast as your finger pushes it and comes back up on its spring.

Fast in, slow out A chart of the button's vertical offset over time. The press drops from zero to two pixels in 60 milliseconds, shown as a steep line. The button is held down while the pointer is held. On release it returns over 200 milliseconds along a decelerating curve. Transition values come from the state being entered press 60ms held down (translate 2px) release 200ms pointerdown pointerup The line dropping means the button moving down into the surface.

A very quick tap can release before the 60ms press completes. Because transitions reverse from their current value, the button simply returns from wherever it reached; the user still sees a small dip. This is also why the press should be short: a 200ms press would barely have started before a quick tap ended.

on touch and keyboard

:active behaves differently across input types, and a good button accounts for each:

  • Mouse: active from pointerdown until pointerup, while hovered. Reliable everywhere.
  • Touch: most browsers apply :active on touch, but some mobile browsers only do so when the page has a touchstart listener somewhere. Adding document.addEventListener('touchstart', () => {}, { passive: true }) once is a well-known, harmless workaround. Even without it, the release transition often remains visible.
  • Keyboard: holding Space on a focused button typically applies :active until the key is released; Enter activates immediately on keydown with little or no visible active state. Keyboard users rely on focus-visible more than on the press, so the focus outline must be strong on its own. Creating Accessible Focus Indicators covers outline contrast.

Finally, remember that activation happens on release for pointer input. The press state is feedback, not the action; users who press and then drag off the button cancel the click, and the button springs back without firing. That forgiving behaviour is worth preserving — do not trigger actions on pointerdown just to feel faster.

Disabled states that still communicate

A disabled button must look unavailable, but it still has to be readable, because a user who cannot find out what is disabled cannot work out why. Muted colours, no shadow, no press movement and cursor: not-allowed together communicate the state. WCAG 1.4.3 exempts inactive components from contrast minimums, yet keeping the label reasonably legible is kinder. Consider whether the button should be disabled at all: a form whose submit button is enabled and shows validation errors on press is often clearer than one whose button is silently greyed out until every field is right.

The disabled attribute also removes the button from the tab order, which hides it from keyboard users entirely. When that is undesirable, aria-disabled="true" keeps the button focusable while script prevents the action, and CSS can style [aria-disabled="true"] exactly like :disabled.

Common mistakes

  • Animating margin-top or top for the press. Both trigger layout, so the button's neighbours can shift by a pixel and the press costs a layout pass on every frame. translate moves the button visually without affecting layout.
  • Transitioning all. A transition: all on a button animates every property that changes, including the focus outline, the cursor-driven colour change and any property a theme switch touches, often with the slow release timing. List the properties that should move. An explicit list also documents the intended motion for whoever edits the button next.
  • Scaling text-heavy buttons. A scale below about 0.95 visibly blurs and shrinks the label during the press. Keep scale subtle or use translation for text buttons.
  • Forgetting the release on reduced motion. Removing translate under prefers-reduced-motion is right, but keep the colour change: feedback that the press registered is not decorative motion, and users who reduce motion still need it.

Variation: press feedback for icon buttons and cards

Flat icon buttons have no shadow to collapse, so a subtle scale works better than translation: scale: 0.94 on :active, with the same asymmetric timing. For whole clickable cards, press feedback should be even smaller — scale: 0.99 or a slight background tint — because large surfaces moving noticeably feel unstable. In every case, pair the motion with a colour change so the feedback survives when motion is reduced.

Browser support

The :active, :disabled and :focus-visible pseudo-classes are supported in every current browser; :focus-visible is supported in Chrome and Edge 86+, Firefox 85+ and Safari 15.4+. The standalone translate property is supported in Chrome and Edge 104+, Firefox 72+ and Safari 14.1+. The hover media feature is supported in Chrome 38+, Edge 12+, Firefox 64+ and Safari 9+, and prefers-reduced-motion in Chrome 74+, Edge 79+, Firefox 63+ and Safari 10.1+.

FAQ

Why does my style not show on mobile? Some mobile browsers only apply :active when the page registers a touch listener, and a quick tap can release before the style paints. A document-level touchstart listener with an empty handler, or relying on the release transition to show feedback, makes the press visible.

Should the press animation be fast or slow? The press itself should be nearly instant, around 50 to 80 milliseconds, so the button responds under the finger. The release can be slower, 150 to 250 milliseconds, which gives a satisfying spring back without delaying the action.

Does apply when a button is activated with the keyboard? Pressing Space on a focused button applies :active in most browsers while the key is held; pressing Enter usually activates immediately without a visible active state. Design the focus and active states so the button is clearly identifiable either way.

How should a disabled button look? Reduce contrast and remove press and hover feedback, but keep the label readable. WCAG exempts disabled controls from contrast minimums, yet users still need to read them to understand why an action is unavailable.

Related articles

More pages in the same section.