Page shells

Patterns for composing page-level layouts by purpose. Each shell defines a layout skeleton — navigation placement, content width, feedback regions — so new pages start from a tested structure instead of a blank canvas.

A shell sits between a template and a pattern. A template names the regions a page has; a shell decides which navigation, which content width, and which feedback surfaces fill them for a given kind of page.

Shell types

Content-first page

• Focus on readable body content
• Constrained content width
• Minimal navigation (breadcrumbs + top nav)
• Used for: articles, documentation, text-heavy pages

640px keeps body copy inside the 45–75 character measure. See Sizing.

Navigation-heavy page

• Sidebar navigation for deep hierarchy
• Content area alongside navigation
• Used for: documentation sites, settings, admin panels

Below the tablet breakpoint the sidebar collapses into a sheet. It does not become a horizontal scroller — a horizontally scrolling navigation hides most of itself.

Form page

• Centered form within a constrained container
• Progress indicator for multi-step forms
• Clear submission area
• Used for: registration, checkout, data entry

Global navigation is deliberately removed from a form page in a flow. A bottom tab bar beside a half-completed transfer is an invitation to abandon it, and the flow already provides its own way back.

Documentation page

• Side navigation with section hierarchy
• Table of contents within content area
• Code examples and interactive previews
• Used for: design system docs, API docs, guides

The TOC rail is hidden below 1100px, where the content column needs the width more than the wayfinding does.

Composition

Each shell combines:

• A template (basic page)
• A navigation pattern (top nav, side nav, breadcrumbs)
• A content layout (constrained, sidebar + content, centered)
• Optional feedback region

Composition table

Every shell has the same regions

Regardless of type, a shell fills the same template regions in the same order — header, navigation, main, optional feedback, footer. The shell chooses what goes in each; it never adds or reorders regions. This is what keeps the skip link, the landmark structure, and the focus order identical across page types.

Mobile collapses shells toward one shape

Below 600px, all four shells converge: single column, --ds-space-4 edge margin, navigation either in the bottom tab bar or suppressed for a flow. The differences between shells are a desktop affordance, which is consistent with a mobile-first system where the phone layout is the design and the desktop layout is that design with room.

Choosing a shell

If a page needs a fifth shell, the first question is whether it is actually one of these four with different content. New shells are expensive — each one is another layout whose focus order, landmarks, and responsive behavior have to be verified independently.

Accessibility

• One <main> per shell, and the skip link targets it.
• Landmark structure is identical across shells, so a returning screen reader user finds the same layout.
• Each <nav> has a distinct aria-label; a documentation page has two and they must be distinguishable.
• DOM order matches visual order in every shell — no order on the layout grid.
• Sticky action bars must not obscure the focused element (SC 2.4.11).

Known gaps

• Shells are documented as compositions, not implemented as components.
• No shell documents its loading or error state at the page level.
• The form shell's sticky action bar is described but has no specified safe-area handling.