Content shell

Use the content shell when hierarchy, reading width, references, and calm progression matter more than application chrome.

Docs surfaceCentered reading widthPattern-first

When to use it Choose the content shell for docs, onboarding, policies, changelogs, and longer articles where page hierarchy should stay obvious.

The content shell is for text-first pages. It keeps the content readable, leaves room for reference blocks, and gives footer navigation a clear role in linear reading flows.

Paragraph width is scoped here through prose wrappers instead of a global element rule, so admin cards, alerts, and dashboards can use full container width.

Why reading width matters

Documentation and article pages work best when the layout keeps reading width stable, separates header metadata from body content, and avoids stretching paragraphs to match application-scale demos.

Need persistent navigation?Use dashboard shell

Operational products should switch to the dashboard frame instead of stretching a content shell into an app shell.

Need grouped form work?Use settings shell

Settings pages need local navigation and sectioned controls, not only article flow.

Reference blocks still use shipped surfaces and primitives

The content shell does not invent its own building blocks. Callouts and link lists are surfaces. Tables remain primitives. Public classification follows UI role, not file path.

Need	Class type	Why
Inline warning	`wb-callout` surface	Keeps emphasis inside the reading flow.
Cross-links	`wb-link-list` surface	Makes adjacent docs or examples easy to scan.
Structured comparison	`wb-table` primitive	Clarifies differences without inventing a new article-specific table style.

Embedded content-shell demo

Content shell example

Use the content shell when hierarchy, reading width, references, and calm progression matter more than application chrome.

Docs surfaceCentered reading widthPattern-first

When to use it Choose the content shell for docs, onboarding, policies, changelogs, and longer articles where page hierarchy should stay obvious.

Why content shells stay narrow

Documentation and article pages work best when the layout keeps reading width stable, separates header metadata from body content, and uses footer navigation for linear progression.

Need persistent navigation?Use dashboard shell

Operational products should switch to the dashboard frame instead of stretching a content shell into an app shell.

Need grouped form work?Use settings shell

Settings pages need local navigation and sectioned controls, not only article flow.

Need	Class type	Why
Inline warning	`wb-callout` surface	Keeps emphasis inside the reading flow.
Cross-links	`wb-link-list` surface	Makes adjacent docs or examples easy to scan.
Structured comparison	`wb-table` primitive	Clarifies differences without inventing a new article-specific table style.