Style Queries: The Game Changer for Your Component Library

Hey! Grab a seat. You know that annoying situation where you want a component to look different depending on whether its parent is "dark mode," "promoted," or "minimalist," but you are tired of passing props down five levels deep or cluttering your HTML with a million BEM modifier classes? We have all been there. You want the child to react to the state of the parent, not just its width.

That is exactly where Style Queries come in. While we have been busy celebrating Container Size Queries, Style Queries have been quietly preparing to revolutionize how we build design systems. They allow us to query the computed values of a parent container—specifically custom properties—and style children accordingly. It is like having a logic engine built directly into your CSS.

How we suffered before

Before Style Queries became a reality, we had two main ways to handle contextual styling, and honestly, both kind of sucked. First, there was the Modifier Class Hell. You would end up with HTML looking like <div class="card card--large card--dark-theme card--borderless">. It was brittle, and if you moved a child component to a different parent, everything broke.

The second way was the Contextual Selector approach. You would write deep selectors like .dark-theme .card .button. This created massive specificity issues that we often tried to solve using pseudo-classes :is() and :where() for clean code. While those helped manage the mess, we were still fundamentally tied to the DOM structure and global class names. If you wanted a child to change based on a dynamic CSS variable, you usually had to reach for JavaScript and a ResizeObserver or some complex React context. Not exactly "lively" or performant, right?

The modern way in 2026

In the modern era of CSS, we treat our components as truly encapsulated units. With Style Queries, the parent component simply defines a state via a CSS custom property, and any descendant can "ask" the parent what that state is. This is much more robust than relying on class inheritance.

The beauty of this is that it doesn't matter where the child is in the tree. As long as it is inside a container that has defined a specific property, it can react. This is perfect for theming. For instance, if you're already using responsive (fluid) typography with the clamp() function, you can use Style Queries to toggle specific font weights or decorative elements based on the "mood" of the container without writing a single line of JavaScript.

Ready-to-use code snippet

Let's look at a real-world example. Imagine a product card that changes the style of its internal "Sale" badge based on a --card-style variable set on the container.


/* 1. Define the container */
.product-card {
  container-name: card;
  --card-theme: vibrant; /* This could be changed dynamically */
  padding: 20px;
  border: 1px solid #ccc;
}

/* 2. The child component with default styles */
.badge {
  padding: 5px 10px;
  background: gray;
  color: white;
  transition: all 0.3s ease;
}

/* 3. The Style Query: Reacting to the custom property */
@container card style(--card-theme: vibrant) {
  .badge {
    background: linear-gradient(45deg, #ff0055, #ffcc00);
    font-weight: bold;
    transform: rotate(-5deg);
    box-shadow: 0 4px 10px rgba(0,0,0,0.2);
  }
}

@container card style(--card-theme: minimal) {
  .badge {
    background: transparent;
    border: 1px solid black;
    color: black;
    text-transform: uppercase;
    font-size: 0.8rem;
  }
}

Common beginner mistake

The biggest trap developers fall into right now is trying to query standard CSS properties like color or margin. While the spec technically allows for querying any computed value, current browser support (and practical implementation) is almost entirely focused on CSS Custom Properties (variables).

If you try to write @container style(color: red), it likely won't work or will be very inconsistent across browsers. Always use custom properties (e.g., --my-state: active) as your "anchor" for Style Queries. It is cleaner, more intentional, and actually works in the environments that support the feature. Think of the custom property as your API between the parent and the children.

🔥 We publish more advanced CSS tricks, ready-to-use snippets, and tutorials in our Telegram channel. Subscribe so you don't miss out!

StackFeed

Style Queries: Container Style Queries