Adapt application layouts to available space while preserving meaning and supported component treatments.
Fluid styles let content reflow as space and text size change. In this guide, fluid describes application layout, not a Liquidify variant or a guarantee that controls automatically adopt native platform layouts. Keep the task, reading order, and action hierarchy recognizable at every supported size.
Start with component variants for their visual treatment and page-owned CSS for the surrounding layout. Use semantic color and spacing tokens rather than copying measurements from an Apple screenshot. A responsive grid, wrapped action group, or stacked label can adapt without changing the meaning of a control.
Use AdaptiveAppLayout when its shell behavior fits the application, then respect its content area and insets. The library can coordinate that shell; the application still decides how its forms, results, and long content use the available space.
Figure in preparation
Fluid styles: interaction sequence
Reflow preserves the task and its reading order.
This class belongs to an application wrapper around related controls; it does not target Liquidify internals.
.preference-actions {
display: flex;
flex-wrap: wrap;
gap: var(--lq-space-12);
padding-block: var(--lq-space-16);
}Wrapping is useful when actions can retain a meaningful order on multiple lines. It does not shrink a single control that is wider than the container. Review long labels and choose a supported alternate composition where necessary.
Use the shipped breakpoint values when defining width-based rules. This documentation site's PostCSS setup resolves @media (--lq-bp-sm) and related aliases from the token manifest. Those aliases require that build integration; they are not native CSS custom-property media queries that work in any consumer stylesheet.
Keep the same data and selection when the layout changes. If the application swaps a navigation or filter presentation, preserve its state above the replaced subtree. Do not reset a draft simply because a viewport crossed a breakpoint.
Reserve room for errors and pending labels. If an action moves into a menu while focused, keep focus on a usable successor. See Overflow content before clipping or truncating content.
Review glass surfaces against the content behind them in light and dark themes. Changing the layout can change that backdrop. Use Color and Materials to evaluate legibility rather than adding more glass layers.
Plan for long labels, localized text, browser zoom, and different input methods. Let essential text wrap where the component supports it. Prefer shorter, clearer wording over unexplained abbreviations used only to make a layout fit.
Keep visual order aligned with DOM order. Review keyboard focus, scrolling, reduced motion, and available space above the browser keyboard. Do not equate a passing width check with a usable layout: inspect controls against the actual padded content bounds and ensure their labels remain readable.
Read Spacing and layout tokens, Layout grid, and AdaptiveAppLayout. Component catalog pages define which size, variant, and wrapping options are supported.