use UI

Master-Detail

Also called list-detail, inbox layout, two-pane navigation

A list of items beside the detail of whichever one is selected.

Example

Spanning tree review

Radia Perlman · 09:14

The loop-free guarantee holds under the failure cases we listed, but the timers need a second look before this ships. Specifically the hold-down interval assumes a converged topology, which is exactly what we cannot assume during a partition.

The address bar right now

?thread=402

Every selection pushes a history entry, so the browser Back button walks back through the threads you opened — and the link you copy opens the one you were reading, not the first in the list.

The selected item carries aria-current="true" rather than a background colour alone, and the two regions are named — “Threads” and “Thread” — so a screen reader user can move between the list and what it opened.

When to use it

  • People move through many items of the same kind — messages, tickets, records — and compare as they go.
  • Keeping the list visible saves repeated navigation back to it.
  • A selected item is worth linking to on its own.

When not to

  • There are five items. Show them all; a list beside a detail is overhead for a set that fits on one screen.
  • The detail needs the full width — a document, a canvas, a wide table.
  • Items are read once and never returned to. A plain list of links to full pages is simpler and faster.

Trade-offs

  • Context and content at once: what you are reading and what is next to it.
  • Moving between items is one click instead of back-and-forth navigation.
  • Each selection is addressable, so a link to “this ticket” works.
  • Two panes need width, so the phone layout is a second design, not a squeeze of the first.
  • The detail pane's scroll position, focus and loading state all have to be reset per selection.
  • Easy to break the back button by holding the selection in component state instead of the URL.

Accessibility

What this pattern needs in order to work for everyone.

Keyboard
  • The list is a list of links. Tab reaches it, Enter follows — arrow-key navigation is optional and, if you add it, must be the full roving-tabindex model.
  • Selecting must not throw focus into the detail pane on desktop; the user is still working the list. On mobile, where selecting is a page change, focus does move to the detail's heading.
  • Going back must restore the list: the same scroll position, and focus on the item that was selected.
Roles and state
  • Mark the selected item with `aria-current="true"`, not just a background colour.
  • Give the two regions names — a `<nav>` for the list, a `<main>`-like region or a labelled section for the detail — so a screen reader user can move between them.
  • Announce the change politely when the detail replaces itself in place, or the pane changes with no signal at all.
  • The detail's heading should name the item, and it should be the first thing in the pane.
Focus
On a phone the panes become two screens: selecting moves focus to the detail heading, and Back returns focus to the item in the list that was chosen.

In the wild

  • Gmail — Selecting a conversation changes the URL; Back returns to the list at the same scroll position.
  • Linear — Issue list and issue detail, each issue addressable, with the list collapsing to its own screen on narrow viewports.

Compared with

Side-by-side breakdowns of patterns that solve a similar problem.