Container queries
Components respond to their container's width, never the viewport — a
table in a half-width dashboard widget compacts while the same table full-width
doesn't. And a build rule with teeth: every @container query
is named; the build fails on a bare one.
The named-container registry
bo-shell the app shell → sidebar collapses to icon rail (≤ 56rem)
bo-table table container → density compaction + col hiding (≤ 30rem)
bo-widget-grid dashboard grid → span-2 widgets collapse (≤ 41rem)
bo-widget each widget → components inside adapt to WIDGET width
bo-stepper the stepper → labels collapse to SR-only (≤ 30rem)Why bare queries are banned
An element cannot query itself: a bare @container resolves against
the nearest ancestor container — whatever that happens to be — or falls
back to the small viewport when none exists. The same rule then means different
things in different placements. This bug class recurred twice in review (a widget
rule that keyed off the app shell; a stepper that collapsed on shell width);
naming the container makes the dependency explicit and the mistake impossible,
so the build enforces it mechanically.
- Thresholds are in rem (beyond-conformance support for users who raise the browser default font size).
- Explicit
data-densitybeats auto-compaction when set on the table or its container itself — see the density rules for the exact precedence. - Compaction may compact — it may not make data unreachable: the data-table reflow requirement (WCAG 1.4.10) is the canonical rule.