Verify the intended query container
The component needs the expected container-type, and complex layouts benefit from container-name so a query does not bind to the wrong ancestor. Inspect the actual container and its inline size before diagnosing why a rule fired.
.card-grid {
container: cards / inline-size;
}
@container cards (min-width: 42rem) {
.card { grid-template-columns: 12rem 1fr; }
}Test either side of the boundary
If a component changes at 672px, test 671, 672 and 673px. Then place it in a main column, sidebar, modal and split view to prove that the same viewport produces the correct local layout.
A custom viewport can help find when the page pushes a container over its threshold, but confirm the container's actual width in browser developer tools.
Apply content pressure
A short English title is not a robust test. Add long Chinese, English and Japanese titles, missing images, long badges, discounts and error states to expose oscillation and overflow near the threshold.
- One-line and three-line titles
- Loaded, missing and broken images
- Zero, one and several actions
- Long translations and right-to-left content
Watch nested containers and feedback loops
Nested components can bind to the nearest unnamed container unexpectedly. Avoid query results that change the queried container's own size and trigger unstable switching. Clear names and responsibilities make dependencies easier to trace.
Keep a useful baseline layout
Build a readable, operable baseline before adding Container Queries. If the feature is unavailable, content order, controls and data should remain usable.