← Home ← Codex ← DEBT ← Engine
Browse by Category
+ added · updated 7d
← Back to glossary

CSS Container Queries

Frontend CSS4 Intermediate
debt(d5/e3/b3/t5)
d5 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'specialist tool catches' (d5). Stylelint and Lighthouse (from detection_hints.tools) can flag some issues, but detecting misuse—like using viewport media queries when container queries are needed—requires understanding component context. The code_pattern notes 'component styles using viewport media queries when the component may appear in different container sizes' which isn't automatically caught without semantic understanding.

e3 Effort Remediation debt — work required to fix once spotted

Closest to 'simple parameterised fix' (e3). The quick_fix shows adding container-type to a wrapper and converting media query syntax to @container syntax. This is a localized refactor within component styles—not a one-liner, but contained within a single component's CSS. Multiple rules may need updating but the pattern is consistent.

b3 Burden Structural debt — long-term weight of choosing wrong

Closest to 'localised tax' (b3). Container queries apply only to web contexts (per applies_to) and affect individual component styling decisions. Once adopted for a component, maintainers must remember the container-type requirement, but the impact is contained to components using this pattern. Not a system-wide architectural choice.

t5 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'notable trap' (t5). The misconception explicitly states developers confuse media queries and container queries as solving the same problem. The common_mistakes reinforce this: forgetting container-type on parent (required but not obvious from @container syntax), and confusion about unnamed container matching. These are documented gotchas that most developers learn, but the initial mental model mismatch is real.

About DEBT scoring →

Also Known As

@container container queries

TL;DR

A CSS feature that lets elements adapt their styles based on their parent container's size rather than the viewport — enabling truly reusable responsive components.

Explanation

Media queries respond to the viewport. Container queries respond to the containing element's size — the same component can render differently when used in a narrow sidebar vs a wide main column. Define a container with container-type, then use @container to write size-dependent styles. Supported in all modern browsers since 2023. Container queries solve the fundamental problem of component-level responsiveness that media queries could never address.

Common Misconception

Media queries and container queries solve the same problem — media queries respond to the viewport (page-level layout); container queries respond to the component's container (component-level layout).

Why It Matters

A card component that looks good in a 3-column grid and in a single-column list requires container queries — media queries cannot express 'when my container is narrow' only 'when the viewport is narrow'.

Common Mistakes

  • Forgetting to set container-type on the parent — @container rules have no effect without it.
  • Using container queries for page-level layout — media queries are still correct for overall page structure.
  • Not naming containers when nesting — unnamed containers match the nearest container ancestor, which may be unexpected.
  • Browser support assumption — container queries require 2023+ browsers; check support requirements.

Code Examples

✗ Vulnerable
/* Media query — can't make component respond to its container:
.card { font-size: 16px; }
@media (max-width: 600px) {
    .card { font-size: 14px; } /* When viewport is small -- but card might be in a narrow column on a wide viewport */
}
✓ Fixed
/* Container query — responds to parent size:
.card-wrapper {
    container-type: inline-size;
    container-name: card;
}

.card { font-size: 16px; display: grid; grid-template-columns: auto 1fr; }

@container card (max-width: 300px) {
    .card {
        font-size: 14px;
        grid-template-columns: 1fr; /* Stack vertically when container is narrow */
    }
}

Added 15 Mar 2026
Edited 22 Mar 2026
Views 81
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings T 1 ping F 1 ping S 1 ping S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 0 pings S 1 ping S 0 pings M 0 pings T 1 ping W 1 ping T 0 pings F 1 ping S 0 pings S 1 ping M 0 pings T 0 pings W 0 pings T 0 pings F 0 pings S 0 pings S 0 pings M 1 ping T 4 pings W 0 pings T 0 pings F
No pings yet today
No pings yesterday
Amazonbot 9 Ahrefs 6 ChatGPT 6 PetalBot 6 Google 5 Perplexity 5 SEMrush 5 Scrapy 3 Unknown AI 2 Applebot 2 Meta AI 1 Majestic 1 Twitter/X 1 Bing 1 Brave Search 1
crawler 50 crawler_json 4
🧱 FUNDAMENTALS — new to this? Start with the ground floor.
Frontend frontend The frontend is the part of a website or application that users see and interact with directly in their browser—buttons, text, images, and forms.

Every user interaction starts at the frontend. Understanding this layer helps you build interfaces people actually want to use and debug issues that only appear in the browser.

💡 If you can see it or click it, it's frontend; if it stores data or makes decisions you shouldn't expose, that belongs on the backend.

Ask Codex about Frontend →
DEV INTEL Tools & Severity
🟡 Medium ⚙ Fix effort: Medium
⚡ Quick Fix
Add container-type: inline-size to a wrapper element, then use @container (min-width: 400px) rules inside — components respond to their container width, not the viewport
📦 Applies To
css CSS4 web
🔗 Prerequisites
🔍 Detection Hints
Component styles using viewport media queries when the component may appear in different container sizes; card component that needs different layout in sidebar vs main
Auto-detectable: ✗ No stylelint lighthouse
⚠ Related Problems
🤖 AI Agent
Confidence: Low False Positives: High ✗ Manual fix Fix: Medium Context: File


✓ schema.org compliant