Inline Conditionals Are On the Way — Style Queries Already Do Most of the Work
The CSS Working Group’s decision to explore inline conditionals has stirred some strong feelings. Detractors worry that bringing explicit logic into CSS will make the language less approachable. But the more interesting question is whether the feature is even necessary — because much of what it promises is already possible with style queries, a technology with solid browser support today.
Conditionality Is Not New to CSS
Lea Verou’s proposal is not introducing a foreign concept. CSS has long been conditional — media queries, container queries, and custom properties all make decisions at runtime. The proposal simply adds a more ergonomic syntax for cases where a small part of a value changes, much like the relationship between an if statement and a ternary operator in JavaScript.
People have already built impressive hacks to simulate inline conditionals with current CSS, and some of them are genuinely hard to follow. But stepping back, the question arises: are developers doing all this work just to avoid writing a wrapper element and using style queries?
It’s reasonable to avoid unnecessary DOM elements, but the complexity of existing workarounds is worth examining. Perhaps the simpler solution — adding a wrapper div and querying its styles — has been overlooked.
The Core Problem: Style Queries Can’t Style the Query Target
Lea’s motivating examples center on setting a --variant custom property on a callout and then styling both the element and its children based on that variant. With style queries, you can almost get there — but you cannot use a style query to style the container that holds the queried property.
.callout {
@container (style(--variant: success)) {
border-color: var(--color-success-30);
background-color: var(--color-success-95);
&::before {
content: var(--icon-success);
color: var(--color-success-05);
}
}
}There are workarounds, like hacking the ::after pseudo-element with z-index to visually suggest the container is styled. That approach fails when the container itself needs structural changes — for example, when Lea’s other example requires setting flex-flow based on a variant. Pseudo-elements cannot handle that.
A Simpler Path: The Wrapper Div
One commenter on the proposal called type grinding — a technique to convert custom property tokens into usable values — “very convoluted.” That assessment is fair: type grinding works, but it quickly gets unwieldy in production code.
A cleaner alternative uses style queries on wrapper divs. Comparing Lea’s flexbox variant sample with a wrapper-based approach demonstrates the trade-off: simpler CSS in exchange for a bit more markup.
The CSS becomes more readable and the markup adds one layer. That is often acceptable. And if inline conditionals eventually land, migrating style queries that use the style() function toward the new syntax is feasible — the two approaches share enough structural DNA. By the time the feature ships, automated migration might even be a reasonable job for AI tools.
But demos often flatter a technique. Would the wrapper approach survive a more realistic scenario?
Putting Wrappers to Work in a Realistic Example
Combining the flexbox sample with an HTML5 form validation example and Seth Jeffery’s pure CSS icon morphing demo produces a more demanding test case. A single custom property drives all visual changes on the callout — border color, icon, background, and content — without ever being used directly in a property value. Instead, style queries read the --variant property declared on the wrapper and translate it into styles.
@property --variant {
syntax: "error | success";
initial-value: error;
inherits: true;
}
body:has(:invalid) .callout-wrapper {
--variant: error;
}
body:not(:has(:invalid)) .callout-wrapper {
--variant: success;
}Nothing prevents JavaScript or inline styles from setting --variant, as in Lea’s examples. The form validation is a means to show that the callout can react to changes dynamically — it is not a restriction on how the property gets its value.
Conclusion: Not a Race, But a Stopgap Worth Using
Inline conditionals are a welcome addition, and their eventual arrival does not mean the current workarounds were wasted. Style queries offer a readable, hack-free way to achieve the same outcomes today. Developers who advocate against inline conditionals may be discounting how much existing CSS already anticipates the feature. But even those who look forward to it can, in the meantime, rely on a technology that is easier to grasp than the elaborate alternatives currently circulating.
