We Might Need Something Between Root And Relative CSS Units For Base Elements

The Gap in Our CSS Unit Toolbox

Modern CSS provides a rich ecosystem of length units for styling web applications. From pixel-based absolute units to flexible relative units like em and rem, developers have choices for creating responsive, scalable designs. However, as component-based architectures become the norm and layouts grow more complex, a gap emerges in our unit toolbox.

We have units relative to the root element (rem), and units relative to the immediate parent element (em), but what about units relative to an intermediate container? This gap has significant implications for building truly modular, responsive components that work consistently across different contexts.

In this guide, we'll explore how container query units fill this critical gap and transform how we approach responsive component design in modern web development.

Root-Relative Units: The rem Foundation

The rem unit, which stands for "root em," has become the cornerstone of scalable typography and spacing in modern web development. Unlike em, rem always calculates its value relative to the font size of the root element (html), providing consistent, predictable scaling across an entire document.

The key advantage of rem lies in its predictability. When you set an element's font size to 1.5rem and the root font size is 16 pixels, that element will render at 24 pixels regardless of any parent element's font size.

When rem Works Best

• Global typography scales and heading hierarchies
• Consistent spacing patterns (margins, padding) across a site
• Any values that should scale proportionally when users adjust their browser's base font size
• Maintaining design consistency across multi-page applications

The Limitation

However, this predictability becomes a limitation in component-based architectures. A card component has no mechanism to "know" about its container's dimensions using rem--it only understands the root font size and its parent's font size.

Element-Relative Units: The em Approach

The em unit represents the font size of the current element, creating a parent-referential system that excels at creating locally proportional designs. When applied to font-size, an em value multiplies against the parent element's computed font size.

The classic use case for em involves creating button components with padding that scales with the button's font size. A button with font-size: 1em and padding: 0.5em 1em creates internal spacing that maintains its proportions as the font size changes.

The Compounding Challenge

However, em introduces complexity through its compounding behavior. Nested elements using em for font-size calculations can unexpectedly grow or shrink as the nesting depth increases:

/* Each level compounds: 1.2 × 1.2 × 1.2 = 1.728 */
.section { font-size: 1.2em; }
.article { font-size: 1.2em; }
.paragraph { font-size: 1.2em; }
/* Final computed size: 1.728× base font size */

When em Works Best

• Component-local proportional sizing
• Button padding and form input sizing
• Nested component typography within the same hierarchy
• Maintaining proportions between text and internal spacing

Container Query Units: The Middle Ground Solution

CSS container queries introduce a new category of relative units specifically designed to address this exact gap. Container query length units allow you to size elements based on the dimensions of their nearest query container rather than the viewport or parent element.

The Six Container Query Units

These units require a containment context established using the container-type property with inline-size or size values. Combined with modern CSS selectors like the CSS :has() selector, container query units unlock powerful new patterns for building adaptable interfaces.

Performance Benefits for Modern Web Development

In the context of modern web development with frameworks like Next.js, container query units align naturally with component-based architectures. Components become truly reusable because they carry their own responsive logic, independent of their placement in the page layout.

Reducing Media Query Complexity

Traditional responsive design relies heavily on media queries that respond to viewport dimensions. Container query units eliminate this limitation by moving the responsive boundary from the viewport to the component's container:

• Component styling logic stays with the component
• No more scattered media query breakpoints across stylesheets
• Components work consistently regardless of page layout
• Easier maintenance and refactoring

Improved Core Web Vitals

Container query units, combined with proper containment, can improve rendering performance:

• Containment tells the browser that the container's contents won't affect external elements
• Browsers can optimize rendering knowing layout is isolated
• Reduced layout thrashing from viewport-relative calculations
• More efficient reflows when components resize

For teams building modular CSS architectures, container query units pair excellently with approaches like CSS Modules for truly encapsulated component styling.

The Future of Responsive CSS

Container query units represent an evolution in how we think about responsive design. Rather than treating responsiveness as a page-wide concern addressed through viewport-based media queries, container query units enable component-level responsiveness that respects actual layout context.

This shift aligns naturally with modern component-based development patterns. As frameworks like Next.js continue to emphasize component architecture, the ability to create self-contained, responsive components becomes increasingly valuable.

The "something between root and relative CSS units" we've needed is not a hypothetical new unit but an entire category of units already available in modern browsers. Container query units fill the gap between root-relative and element-relative sizing, enabling truly modular, context-aware components that maintain their proportions across any placement.

The Complete Responsive System

The combination of all three unit types creates a complete system for responsive design:

1. rem - For document-wide scaling from a single control point
2. em - For component-local proportions within hierarchies
3. cqw/cqh - For context-aware component sizing based on placement

Mastering when to use each unit type--and combining them strategically--transforms how you approach responsive web development, creating more maintainable, performant, and truly modular designs.

Sources

1. MDN Web Docs - CSS Container Queries
2. MDN Web Docs - Container Query Length Units
3. Refine.dev - rem vs em: Everything you need to know
4. Web.dev - Container queries in action