Hero section with CQ
Responsive hero that adapts to container width using container-type and @container — no media queries.
Build something amazing
Create beautiful, responsive interfaces that adapt to any container size. No media queries needed.
Quick implementation
/* HTML:
<div class="hero-container">
<div class="hero">
<div class="hero-content">
<h2>Title</h2>
<p>Description</p>
<div class="hero-actions">...</div>
</div>
<div class="hero-visual">...</div>
</div>
</div>
*/
.hero-container {
container-type: inline-size;
container-name: hero;
width: 100%;
}
.hero {
display: grid;
gap: 2rem;
padding: 2rem;
}
/* Default: single column */
.hero-content {
padding-right: 0;
}
.hero-visual {
display: none;
}
/* Wide container: 2 columns */
@container hero (min-width: 48rem) {
.hero {
grid-template-columns: 1fr 1fr;
align-items: center;
}
.hero-content {
padding-right: 2rem;
}
.hero-visual {
display: flex;
}
}
/* Narrow container: compact spacing */
@container hero (max-width: 32rem) {
.hero {
padding: 1.5rem;
}
.hero-actions {
flex-direction: column;
}
.hero-btn {
width: 100%;
}
}
Prompt this to your LLM
Includes role, constraints, two framework variants, and edge cases to handle.
You are a senior frontend engineer specializing in modern CSS layout.
Goal: Build a hero section component that adapts its layout based on container width using container queries.
Technical constraints:
- Use container-type: inline-size with container-name on the outer wrapper.
- Use @container queries instead of @media for all layout changes.
- Use oklch() for all colors (gradients, backgrounds, text) instead of hex or rgba().
- Include a 2-column layout for wide containers (min-width: 48rem) and single-column for narrow.
- Add a @media (prefers-reduced-motion: reduce) rule to disable animations on buttons.
Framework variant (pick one):
A) Vanilla HTML + CSS only with container queries.
B) React component — accept `children`, `className`, `variant` (compact | standard | wide) props; container query applied to wrapper div.
Edge cases to handle:
- What happens if container queries are not supported? Provide a @media fallback.
- Handle very narrow containers (< 20rem) with stacked, full-width buttons.
- ARIA: ensure interactive elements are keyboard accessible with focus-visible styles.
Return HTML + CSS, clearly separated.
Why this matters in 2026
Container queries flip responsive design on its head. Instead of asking @media (min-width: 768px), you ask @container hero (min-width: 48rem) — the component adapts to its parent, not the viewport. This means the same hero works in a sidebar, a modal, or full-width without breakpoints tied to screen size.
Container queries are now Baseline Widely Available, so you can drop the mobile-first cascade and let components truly be reusable across any layout context.
The logic
container-type: inline-size establishes an inline-size container. The container-name: hero gives it a name for use in @container hero (...) rules. Inside those rules, you style children as if querying the container's width, not the viewport.
Why container over media? A hero in a 300px sidebar should look compact even on a 4K screen. Media queries can't know that. Container queries can. The grid-template-columns switches from 1 to 2 columns based on the container, not the browser window.
Progressive enhancement: Older browsers ignore @container and show the default layout. No JavaScript needed, no resize listeners — just CSS.
Accessibility & performance
All interactive elements (buttons, links) must have visible focus states. The demo uses :focus-visible with a high-contrast outline. Performance is excellent: container queries are evaluated by the layout engine, not JavaScript. No repaint on window resize unless the container itself changes size.
hero, card, sidebar) to make @container rules self-documenting.