Mixing the two needs an explicit split of jobs

What it is

A common pattern: the shell snaps at a few widths (hamburger / sidebar / two-pane), and columns and type inside a band flow with width. Mixing is fine if you write down who snaps, who flows, in which band. Confusion is the same property sometimes flowing and sometimes snapping: the page adaptively becomes two columns at 900, while an inner card grid auto-fills into three. Authors and testers cannot predict the count.

If the split is tacit, one viewport performs two strategies at once.

Why it happens

Fluid and adaptive are two time-scales. Interpolation changes size; a snap changes topology. Each property (column count, nav shape, padding, type size) has to be labelled as one, with a width interval. The same property both snapping and creeping in one interval kills the prediction model: QA does not know whether to screenshot samples or drag; engineering does not know whether to write a media query or a fraction.

Nesting is the blast zone. Page-level adaptive plus component auto-fill or container queries: the outer says “desktop two-pane now,” the inner says “I have 280 px, I stack.” Both are correct; the page looks broken.

Where it stops holding

A small site that uses only one strategy does not need this job table. The moment a shared kit is nested by several teams, the table is an interface: shell team owns snaps, component team owns flow, or the reverse — not both owning column count.

Motion can ease from one structure to another. That visualises a snap; it does not make the property fluid.

Applying it

• Make a module × property × {flow | snap at W} table. Column count, nav, type size, padding all get a cell. A cell with both: split the interval or delete one.
• Ban page media queries and inner auto-fill both deciding “how many columns” without a stated winner.
• How to check: audit against the table. A property claimed to flow should move smoothly over a 40 px drag, not jump. A property claimed to snap should change topology only at the written W. Anything that both jumps and creeps: note the width and edit the table down to one behaviour. Then look at the deepest nest (a card grid in a rail) and see whether column count is still derivable from the table. If not, the split is unfinished.

Related

• Same group: F2.11.1 Fluid layout interpolates as width changes · F2.11.2 Adaptive layout jumps at a breakpoint
• Nearby: F2.15 Container queries and component-level response · F2.10 Responsive breakpoints · F2.03 Spacing scale
• Search terms: hybrid responsive · auto-fill · layout strategy · container query