Modern CSS continues to offer innovative, simplified solutions to long-standing design challenges. However, these advancements often introduce new possibilities beyond mere problem-solving. Container queries exemplify this, presenting exciting new avenues for layout design. Their similarity to media queries, however, can lead to underutilization of their unique capabilities.
While media queries were instrumental in responsive web design, they possess inherent limitations. They lack contextual awareness, relying primarily on viewport size and the browser's initial font size (not the root font size defined in your CSS).
Consider this example:
html { font-size: 32px; } body { background: lightsalmon; } @media (min-width: 35rem) { body { background: lightseagreen; } }
Intuitively, one might assume the background color changes at a viewport width of 1120px (35rem 32px). This is incorrect. Media queries only consider the browser's initial* font size (typically 16px, but user-adjustable), as specified in the media query specification: relative length units are based on the initial value, independent of declared values.
This design choice prevents infinite loops in scenarios like:
html { font-size: 16px; } @media (min-width: 30rem) { html { font-size: 32px; } }
Container queries, in contrast, offer superior intelligence. They directly assess the container's size, eliminating the need for "magic numbers" in breakpoints.
For instance, to create a three-column grid at larger sizes, a media query requires precise breakpoint calculation. With container queries, we define the minimum column width, and the layout adapts accordingly. If we want three 300px columns, we know a 900px container will suffice. This wouldn't work reliably with media queries due to the variability of container sizes within the viewport. Furthermore, container queries support any unit, including ch
(character width), allowing for layout based on text content.
Example:
.grid-parent { container-type: inline-size; } .grid { display: grid; gap: 1rem; @container (width > 90ch) { grid-template-columns: repeat(3, 1fr); } }
This approach is further enhanced by the use of calc()
within container queries (as suggested by Miriam Suzanne): @container (width > calc(30ch * 3))
.
Practical Considerations and Workarounds:
Container queries require a defined container element. This necessitates wrapping elements, which can be cumbersome, especially with grid or flex items. However, using repeat(auto-fit, ...)
allows the main grid to serve as the container:
.grid-auto-fit { display: grid; gap: 1rem; grid-template-columns: repeat(auto-fit, minmax(min(30ch, 100%)), 1fr); container-type: inline-size; }
This enables styling based on the number of columns:
/* 2 columns + gap */ @container (width > calc(30ch * 2 + 1rem)) { ... } /* 3 columns + gaps */ @container (width > calc(30ch * 3 + 2rem)) { ... }
While custom properties for breakpoints would enhance developer experience, the current functionality offers significant advantages.
Flexbox Considerations:
Container queries can be applied to flexbox, but padding and borders on flex items are not considered by the flexbox algorithm, potentially leading to unexpected layout shifts. Therefore, grid is often preferred for this type of responsive layout.
In conclusion, container queries offer a more intelligent and flexible approach to responsive design, surpassing the limitations of media queries and unlocking new creative possibilities.
The above is the detailed content of 'Smart” Layouts With Container Queries. For more information, please follow other related articles on the PHP Chinese website!