The Problem: One Component, Many Contexts
Why Media Queries Aren't Enough
Prof. Teeters showed me a product card component that appears in three places on the same page:
📊 Sidebar
250px wide
Media queries only know the viewport width (like 1200px for desktop). Your card can't tell
if it's in the sidebar or main content – it only knows the screen is desktop-sized.
📊 Main Grid
400px wide
Cards in the sidebar look wrong with desktop styles, so developers create multiple versions:
card-small, card-medium, card-large.
📊 Featured Section
800px wide
This means duplicate code and harder maintenance. Container queries solve this problem.
HAP's Component Breakthrough:
Container queries seemed so abstract until Prof. Teeters showed me a real sidebar problem. The same card component looked perfect in the main area but completely broken in the narrow sidebar – all because media queries only knew about screen width! When she showed me @container, I finally understood why developers have been wanting this feature for years. It's component-based design done right!
The Key Difference
Media Query Logic
"The screen is 1200px wide, so use desktop styles"
(Every component gets the same styles)
Container Query Logic
"My container is 250px wide, so use compact styles"
(Each component adapts to its actual space)
🎯 HAP's Visual Example: The Card Component
When I saw this, everything made sense! Same component code, three different layouts based on container width.
Product Name
$99.99
This card adapts...
Sidebar (250px)
Product Name
$99.99
This card adapts to its container
Grid (400px)
Product Name
$99.99
This card adapts to its container
Featured (Full Width)
How Container Queries Work
Step 1: Define a Container
Prof. Teeters taught me: First, you mark an element as a container. This tells the browser "child elements can query my size."
Most common type:
container-type: inline-size (queries width only)
Step 2: Write Container Queries
Instead of @media, you use @container:
@container (min-width: 400px)– when container is at least 400px wide@container (max-width: 300px)– when container is at most 300px wide
Step 3: Components Adapt Automatically
The component adjusts its layout based on available space, not screen size. One component works everywhere.
Just like viewport units (vw, vh), containers have their own units:
cqw– 1% of container widthcqh– 1% of container height
Example Use: A heading that scales with its container:
font-size: 5cqw
This means typography can scale smoothly based on component size, not screen size.
Real-World Use Cases
Product Cards
- In sidebar: Shows price and title only
- In grid: Adds product image and rating
- Featured: Shows full description and reviews
Dashboard Widgets
- Charts that switch from icons to labels when space allows
- Tables that show/hide columns based on container width
- Data visualizations that scale smoothly
Article Previews
- Narrow: Headline and date only
- Medium: Adds excerpt and thumbnail
- Wide: Include author info and tags
🎯 When to Use What
When to Use Container Queries
- Reusable components (cards, widgets)
- Sidebar content
- Grid items
- Dashboard panels
Keep Media Queries For
- Overall page layout
- Navigation breakpoints
- Global typography
- Footer/header changes
The Bottom Line
Container queries let components be smart about their own space. Instead of guessing based on screen size, components adapt to their actual containers.
Think of it this way: media queries are for page-level decisions, container queries are for component-level decisions. Use both together for complete responsive control!
🟠 Why This Matters
Container queries complete the responsive design toolkit. Components become truly reusable – build once, use anywhere. No more creating multiple versions of the same component for different contexts.
The Impact:
- Less CSS to maintain
- More consistent designs
- Truly modular components
- Better performance (no JavaScript detection needed)