"For this announcement card, we want the image side-by-side in the main top area, but stacked vertically when placed in the sidebar"—in client web development, requests to slightly tweak the same visual component depending on its placement arise every day. However, media queries (@media), long used for responsive branching, can only branch based on the width of the screen (viewport). They cannot determine whether the card itself is "currently placed in a narrow or wide area." As a result, teams build separate cards for the main column and the sidebar, duplicating similar code two- or three-fold. Components once created in client projects become "placement-specific" and cannot be reused, forcing teams to remake similar components for every project—this is a common debt that accumulates on sites built solely with media queries.
Container queries solve this issue. In Interop 2026 (web.dev), curated by web.dev in 2026, container queries continue to be refined as an infrastructure that can be used reliably across browsers, and they have now reached a stage where they can be taken for granted in production. With container queries, components can look at the "width of their containing area" and switch layouts on their own. In this article, we outline how to use container queries as a tool to create "bulletproof, reusable UI anywhere" in client development.
Why media queries alone prevent component reuse
The concept of building responsive layouts with media queries determines layouts based on "whether the screen is wide or narrow." While this works well for defining the skeleton of an entire page, it fails at the component level.
The reason is that even at the same screen width, the available width differs depending on where a component is placed. Even on desktop (screen width of 1200px), a card placed in the main column can use 800px, while the exact same card placed in the sidebar can only use 280px. Because media queries only look at screen width, writing "make it side-by-side because the screen is wide" causes even the narrow card in the sidebar to be laid out horizontally, squeezing and crushing it.
To work around this discrepancy, teams on the ground tend to create variations for each placement, such as "main column card," "sidebar card," and "footer card." Despite looking almost identical, they maintain separate HTML classes and CSS. Consequently, even a minor tweak to the card's design requires modifying all variations across the board. In client development, this "building separate versions of the same thing" quietly drives up both production and maintenance hours.
Container queries change this baseline entirely. By shifting the evaluation axis from "screen width" to "parent element (container) width," components can determine their layout by looking at the actual horizontal space available to them. The same card can automatically switch to side-by-side when placed in the main column and vertical when placed in the sidebar, all with a single block of code.
Container query basics: defining the "measuring parent" and the "observing child"
Think of container queries in two steps. First, declare the parent element you want to use as a baseline as a "container" (the measuring parent), and then have child elements inside switch their styles based on the parent's width (the observing child).
/* 1. 測る親：このエリアを幅の基準（コンテナ）にする */
.card-area {
container-type: inline-size; /* 横幅を測れるようにする */
container-name: card-area; /* 名前を付けておくと指定しやすい */
}
/* 2. 見る子：親(card-area)が400px以上のときだけ横並びにする */
@container card-area (min-width: 400px) {
.card {
display: grid;
grid-template-columns: 160px 1fr; /* 画像とテキストを横並びに */
}
}The key point is that the condition in @container evaluates the "container width" rather than the "screen width". While .card itself remains the exact same code, it renders side-by-side when .card-area is wide, and vertically when narrow (not satisfying the condition). Placing this .card in an 800px main column displays it side-by-side, while placing it in a 280px sidebar displays it vertically—the component adapts on its own simply by changing its placement.
Shifting from the approach of creating "placement-specific dedicated parts" via classes to having elements act based on their own size follows the same philosophy of "giving elements ownership of their position and behavior," as discussed in our article on CSS anchor positioning.
A "component-driven" build structure that works in client development
The true value of container queries lies not just in their isolated convenience, but in their ability to transform design strategy. When components no longer depend on where they are placed, sites can be assembled "component by component" rather than "page by page."
| Dimension | Media query-centric | Container query combination |
|---|---|---|
| Branching baseline | Screen width | Width of the area where the component is placed |
| Visually identical components | Built separately for each placement | Reuse a single component |
| Design modifications | Cross-modify all variations | Updating one place reflects everywhere |
| Reuse in other projects | Hard to reuse due to fixed placement assumptions | Easy to export as portable components |
This "reuse a single component" architecture becomes increasingly valuable the more sites you handle in client development. This is because card and list components properly built once become placement-agnostic "assets." When similar components are needed in the next project, they can be brought over rather than built from scratch. Organizing components into patterns and standardizing naming and responsibilities becomes even more robust when combined with the design-system organization covered in our article on sharing values with CSS custom functions.
In addition, container queries support not only "width," but also style queries that branch based on the values of CSS variables set on the container. For example, you can give a container a state variable such as "this container has a dark tone," and switch the colors of internal components according to that value. Branching layout by size and decorative texture by state—separating these concerns—is a major strength of modern container queries.
Pitfalls when adopting it in client web development
On a media site whose maintenance we took over (company name withheld), article cards had fractured into four variations: "for the top page," "for category lists," "for related articles," and "for the sidebar." Although visually almost identical, their HTML and CSS were completely separate; every time a request came to slightly alter the card design, all four locations had to be updated without omission. In fact, an incident had occurred in the past where one location was missed, leaving only the related articles card with an outdated design.
We consolidated these four variations into a single card component using container queries. Each area where cards are placed (main column, sidebar, etc.) was made a container-type: inline-size container, and the card component was given a single rule: "display side-by-side if the parent is wide, and vertically if narrow." Four sets of HTML and CSS became one, and design updates made in a single place were reflected everywhere. All we did was collapse components that had splintered by placement into a single component that adapts by looking at its own size.
The most valuable lesson from this project was being mindful that establishing a container alters the sizing context within it. Because an element specified with container-type: inline-size serves as the baseline for internal layout calculations, unexpected height collapsing can rarely occur. It is safer to draw a boundary: limit containers strictly to "areas where components are arranged," and avoid turning entire pages into containers indiscriminately.
Another pitfall is over-engineering fallbacks for container queries. While container queries are widely implemented, even when considering legacy environments, you can keep migration risks minimal by using existing media query-based layouts as a foundation and layering container queries on top as a progressive enhancement to "adapt more intelligently." Moving forward with well-scoped blast radiuses instead of rebuilding all components at once is the safest path in client development.
Where to begin
Removing the assumption that "layouts can only branch by screen width" changes how components are built. If you are building separate components of the same appearance for each placement, there is a high probability they can be collapsed into one using container queries. Collapsing them allows design modifications to be handled in one place and makes porting to subsequent projects much easier.
As a first step, we recommend picking one "component currently built separately for each placement," making its containing area a container, and consolidating the component into "a single rule that branches on parent width." Once you confirm that layouts switch as intended across different placements, you will have achieved production-grade quality.
If you are struggling with inflated production hours from creating similar components, fear missed updates across multiple locations during design revisions, or want to reuse components as valuable assets, please reach out via GleamHub's contact page. We will inspect your current component architecture and work with you to design a gradual shift toward placement-independent, reusable components.
