Organize content with consistent alignment, flexible columns, and a reading order that survives reflow.
A layout grid provides shared alignment for content and actions. Choose its structure from the task: a settings form, a collection of cards, and a reading page need different arrangements. Liquidify supplies spacing and breakpoint tokens, but the application owns its content grid and responsive rules.
Place the page purpose and primary content early in the reading order. Align related headings, fields, and actions so people can scan between them. Use fewer columns when a task depends on reading a sequence; use repeated columns when people need to compare equivalent items.
Keep navigation distinct from content. Choose AdaptiveAppLayout for its supported application shell behavior, then compose the content inside it. A shell does not decide the column count or reading order of that content.
Figure in preparation
Columns that preserve reading order
A two-column content grid reflows into a single ordered column.
Use CSS Grid or Flexbox on an application-owned container. Begin with a single readable column. Add columns only when the available space supports the content, including long labels and enlarged text. Preserve DOM order when reflowing so visual order and keyboard navigation remain understandable.
This example shows two equal columns above a chosen breakpoint. It is an application layout, not a Liquidify Grid component or a required column system.
.preference-grid {
display: grid;
grid-template-columns: minmax(0, 1fr);
gap: var(--lq-space-24);
padding: var(--lq-space-16);
}
@media (min-width: 48rem) {
.preference-grid {
grid-template-columns: repeat(2, minmax(0, 1fr));
}
}The 48rem threshold matches the installed --lq-bp-md token. CSS custom properties cannot be substituted directly into media-query conditions. Use a build-time breakpoint mechanism when the application provides one; otherwise keep the literal condition aligned with the token source. Load the Liquidify aggregate stylesheet before using its variables.
| Decision | Implementation starting point |
|---|---|
| Space between peers | A gap using the --lq-space-* scale |
| Space inside the content boundary | Container padding using spacing tokens |
| Viewport threshold | --lq-bp-sm through --lq-bp-2xl as breakpoint references |
| Column proportions | Application-owned CSS grid tracks |
| Navigation and bars | The supported layout component's slots and behavior |
The installed web breakpoints are 40rem, 48rem, 64rem, 80rem, and 96rem. They are reference thresholds, not device detection or SwiftUI size classes. There is no verified exported general-purpose Grid or Stack primitive, and this page does not impose Carbon's 2x Grid measurements.
Check the space available inside the content region, not only the browser width. Sidebars and inspectors can leave a wide viewport with a narrow content column. Verify at intermediate widths as well as the extremes.
Allow rows to grow with text. Check zoom, long unbroken values, translated labels, and keyboard focus outlines. Keep controls inside their padded containers. Where an application shell already manages bar insets or scrolling, avoid adding a second competing inset or scroll container without a specific need.