VOCABULARY / ENTRY
Adaptive Multipane Layout
adaptive-multipane
Lets the same set of panes gain, merge, or split columns based on available width or container size — two or three panes side by side on a wide window, collapsing to a single pane with a way back on a narrow one. It governs only that reorganization, not what kind of information any individual pane carries.
Recognizing it
- The same set of panes shows two or three columns side by side on a wide window and collapses to a single column with a back or switch affordance on a narrow one
- Merging or splitting the pane count is triggered by viewport or container-width breakpoints, not by the person manually switching layout modes
- The current selection and scroll position are preserved across the pane-count change wherever feasible, rather than resetting to an initial state
Concept boundary
Adaptive multipane layout describes how one set of panes gains, merges, or splits columns across screen widths or window shapes, and what must be preserved or may be deferred when that happens. It does not redefine what belongs inside any single pane or how panes relate to each other — a list selection driving a detail view is master-detail's job, a narrower reference or citation pane is supporting-pane's job, and a persistent cross-page navigation or tool region is sidebar-layout's job. In short, those layouts answer "what is in the panes and how do they connect," while adaptive multipane layout only answers "how does this same set of panes reflow as the window gets narrower or wider."
When to consider it
- A multi-pane experience needs to work on phones, tablets, and wide windows alike, and content on a narrow screen must not simply disappear
- The app can run at in-between sizes such as split screen or a resizable desktop window, and needs a smooth transition rather than an abrupt jump at fixed breakpoints
- The product already uses master-detail, supporting-pane, or sidebar-layout (or a combination of them) and needs one consistent reflow rule shared across all of them
When to be cautious
- The product targets only one fixed device width and never needs to reflow across sizes
- The problem to solve is what belongs inside a pane, or how panes relate to each other — that is master-detail's, supporting-pane's, or sidebar-layout's job, not this one
- The plan is to drop a pane's content on narrow screens with no substitute entry point — that violates the baseline of keeping content reachable and should not be adopted as an adaptive approach
Tradeoff
Experience stays coherent and content stays reachable across devices and window shapes, but each breakpoint needs its own merge/split rule, and in-between sizes such as a resizable window must be tested for a smooth transition rather than an abrupt jump between two or three fixed breakpoints.
Conditional rules · Editorial advice
Related entries
Adaptive multipane layout only defines how this set of panes merges into one column or splits into more, without changing master-detail's own semantics of a list selection driving the detail content.
Adaptive multipane layout is responsible for letting the supporting pane collapse into a reachable entry point on narrow screens, while the reference or source content shown inside it is still defined by supporting-pane layout.
Single-column layout only describes the single-pane experience itself; adaptive multipane layout describes the process of converging from multiple columns down to one, and that narrow-screen end state is often single-column layout.
Sources and what they support
Explains that container queries let a layout change style and arrangement based on a container's own inline size rather than the viewport, so the same component or pane structure can reorganize its presentation at different container widths without relying on global viewport breakpoints.
Retrieved: 2026-09-15 · Archived 2026-09-16Requires that content be presentable at a width equivalent to 320 CSS pixels without loss of information or functionality and without requiring two-dimensional scrolling (except for parts of the content that require two-dimensional layout for their use or meaning); this Success Criterion is Level AA, and it sets the floor for how narrow a collapsed multipane view may go and whether horizontal scrolling is allowed.
Retrieved: 2026-09-15 · Archived 2026-09-16Definitions reference these sources. Digital specimens, selection advice, relationships, and recipes are editorial work and have not been validated through user research.
Type extensions and implementation notes
No operable specimen yet; the illustration is an editorial sketch. When applied to a product, still verify: whether the merge/split at each breakpoint meets the requirement of no two-dimensional scrolling at a width equivalent to 320 CSS pixels; whether the collapsed pane's entry point has a text or accessible name; whether the current selection and scroll position are preserved across a pane-count change; and whether in-between sizes such as a resizable window or split screen transition smoothly rather than jumping abruptly.
{
"states": [
"three-pane",
"two-pane",
"single-pane"
],
"a11y": [
"The pane-count change does not disrupt the current focus order; the element focused before the change remains keyboard-reachable in the new layout",
"The collapsed navigation affordance (such as a back button or tab) has a text or accessible name, not just an icon",
"When collapsed to a single pane, the reading order matches the visual order and no leftover horizontal scrolling remains"
],
"motion": "The pane-count transition may use a brief animation and should respect the reduced-motion preference"
}Open the Agent JSON file for this entryThis file repeats every field of this entry verbatim and adds its sources, archive status, and editorial scope.