/responsive-paradigms

name: responsive-paradigms
description: Mobile, tablet, and desktop are different interaction paradigms — not the same layout scaled up or down. Sections can be hidden, repositioned, or made sticky on mobile. Navigation and primary actions move. Use when designing responsive layouts, adapting desktop UI for mobile, or deciding what to show on each breakpoint.
metadata:
  priority: 8
  pathPatterns:
    - "**/*.css"
    - "**/*.scss"
    - "**/*.tsx"
    - "**/*.jsx"
    - "tailwind.config.*"
    - "design-system/**"
    - "components/**"
  promptSignals:
    phrases:
      - "responsive"
      - "mobile"
      - "tablet"
      - "breakpoint"
      - "desktop"
      - "adaptive"
      - "bottom nav"
      - "hamburger"
      - "touch"
      - "logo"
      - "header"
retrieval:
  aliases:
    - responsive design
    - mobile layout
    - tablet layout
    - breakpoints
    - adaptive UI
    - bottom navigation
    - mobile navigation
    - responsive logo sizing
  intents:
    - design for mobile
    - adapt desktop layout to mobile
    - decide what to show on each breakpoint
    - design mobile navigation
    - handle layout changes at breakpoints
  examples:
    - how should this sidebar behave on mobile
    - design the mobile version of this dashboard
    - what changes between desktop and mobile for this layout

Responsive Paradigms

Mobile, tablet, and desktop are fundamentally different interaction contexts. The input method, screen real estate, viewing distance, and session intent all differ. Responsive design is not the same layout at different widths — it is a different design decision at each breakpoint.

The Three Paradigms

Mobile (< 768px)

• **Input:** Touch — fingers, not a cursor. Tap targets ≥ 44×44px.
• **Navigation:** Bottom tab bar (thumb reachable) or hamburger drawer. Top navigation is hard to reach.
• **Session:** Often interrupted, task-focused, shorter. Show the most important thing first.
• **Content:** Single column. Vertical scroll only. No hover states.
• **Primary action:** Floating action button (FAB) or full-width button at the bottom of the screen.

Tablet (768px–1024px)

• **Input:** Touch and sometimes keyboard/trackpad. Hybrid paradigm.
• **Navigation:** Can support a persistent sidebar at landscape orientation; collapses to drawer at portrait.
• **Content:** Two-column layouts work. Master-detail patterns (list + detail side by side) are natural.
• **Primary action:** Can be in-line with content, not necessarily floating.

Desktop (> 1024px)

• **Input:** Mouse with hover states, keyboard shortcuts, precise clicking.
• **Navigation:** Persistent sidebar or top navigation. Both visible simultaneously.
• **Content:** Multi-column, dense information, toolbars, context menus.
• **Primary action:** In-context with content, supported by keyboard shortcuts for power users.

---

Section Behaviour Across Breakpoints

Not every section needs to appear on every breakpoint at the same position — or at all.

Sections can be hidden on mobile

Secondary content (related articles, supplementary sidebars, decorative illustrations) can be hidden below a breakpoint. Ask: does a mobile user need this? If no, `display: none` at mobile is correct.

Stacking is the default; repositioning is allowed within the same container

The default responsive move is simply to **stack** — a horizontal row of blocks becomes a vertical column as the viewport narrows. This preserves order and grouping, so the user's mental model of the page survives the breakpoint unchanged. Reach for it first.

**Repositioning an element is also allowed — but only if it stays within roughly the same container area / region.** A sidebar that sits to the left on desktop can move below the main content on mobile, or collapse into an expandable section: it's still "the stuff next to / around the main content", just re-flowed. That's fine.

What to avoid: repositioning that **moves an element into a different container or scope** — a control lifted from its card into the global header reads as a different UI, not a reflow. Keep the parent region stable; change only how it flows within it.

Desktop:              Mobile:
[Main] [Sidebar]  →   [Main]
                       [▼ Related]  ← collapsed accordion, still "around the main content"

Sticky behaviour can change per breakpoint

An element that is `position: sticky` on desktop may need to become a fixed bottom bar on mobile, or be removed from sticky positioning entirely to free up screen space.

.toolbar {
  position: static; /* mobile: inline, not sticky */
}

@media (min-width: 1024px) {
  .toolbar {
    position: sticky;
    top: var(--header-height);
  }
}

Navigation transforms completely

| Desktop | Mobile | |---|---| | Persistent top nav or sidebar | Bottom tab bar or hamburger drawer | | Visible labels + icons | Icons only (bottom nav) or full list (drawer) | | Hover states on nav items | None — touch only | | Dropdowns on hover | Tap to expand, full-screen or sheet |

Labels can be shortened — but the full meaning must be recoverable

As space tightens, a label can be **shortened** or dropped to **icon-only**. Shortening hides information, so keep the full version reachable — the same "clamp + recover" contract as truncated text (see [[repeated-component-alignment]]):

• **Recover it** via `title` / `aria-label` (required for icon-only controls), or in a detail view / the desktop layout.
• **Icon-only** is valid *only if the icon is unambiguous* and still carries its label via `aria-label`. A cryptic icon is worse than the long word.

---

Mobile-First Approach

Design and build mobile first, then enhance for larger screens. Mobile forces prioritisation — what makes it onto mobile is what actually matters.

/* Mobile first: base styles are mobile */
.container { padding: var(--space-4); }

/* Enhance for larger screens */
@media (min-width: 768px) {
  .container { padding: var(