Geoff’s publish concerning the CSS Working Group’s choice to work on inline conditionals impressed some drama within the feedback part. Some builders are excited, however it angers others, who concern it should make the way forward for CSS, effectively, if-fy. Is that this a slippery slope right into a hellscape overrun with rogue builders who abuse CSS by implementing extreme logic in what was meant to be a styling language? Nah. Even when some jerk did that, no mainstream weblog would ever publish the ramblings of that hypothetical nutcase who goes round placing loopy logic into CSS for the sake of it. Due to this fact, we all know the way forward for CSS is protected.
You say the entire world’s ending — honey, it already did
My thesis for at the moment’s article gives additional reassurance that inline conditionals are most likely not the harbinger of the tip of civilization: I reckon we are able to obtain the identical performance proper now with type queries, that are gaining fairly good browser help.
If I’m proper, Lea’s proposal is extra like syntactic sugar which might typically be handy and permit cleaner markup. It’s amusing that any panic-mongering about inline conditionals ruining CSS is perhaps equal to catastrophizing including a ternary operator for a language that already helps if statements.
Certainly, Lea says of her proposed syntax, “Similar to ternaries in JS, it might even be extra ergonomic for instances the place solely a small a part of the worth varies.” She additionally mentions that CSS has at all times been conditional. Not that conditionality was ever verboten in CSS, however CSS isn’t at all times superb at it.
Offered! I need a conditional oompa loompa now!
Me too. And plenty of different individuals, as confirmed by Lea’s curated listing of amazingly complicated hacks that folks have found for simulating inline conditionals with present CSS. A few of these hacks are sophisticated sufficient that I’m nonetheless not sure if I perceive them, however they actually have cool names. Lea concludes: “For those who’re conscious of some other strategies, let me know so I can add them.”
Hmm… certainly I used to be lacking one thing relating to the issues these hacks clear up. I famous that Lea has a doctorate whereas I’m an fool. So I scrolled again up and reread, however I couldn’t cease considering: Are these individuals doing all this work to keep away from placing an additional div round their widgets and utilizing type queries?
It’s honest if individuals wish to keep away from superfluous components within the DOM, however Lea’s listing of hacks reveals that the alternate options are tremendous complicated, so it’s value a shot to see how far type queries with wrapper divs can take us.
Motivating examples
Lea’s motivating examples revolve round setting a “variant” property on a callout, noting we are able to nearly obtain what she needs with type queries, however this hypothetical syntax is unfortunately invalid:
.callout {
@container (type(--variant: success)) {
border-color: var(--color-success-30);
background-color: var(--color-success-95);
&::earlier than {
content material: var(--icon-success);
coloration: var(--color-success-05);
}
}
}She needs to set kinds on each the container itself and its descendants based mostly on --variant. Now, on this particular instance, I might get away with hacking the ::after pseudo-element with z-index to provide the phantasm that it’s the container. Then I might type the borders and background of that. Sadly, this answer is as fragile as my ego, and in this different motivating instance, Lea needs to set flex-flow of the container based mostly on the variant. In that scenario, my pseudo-element answer just isn’t adequate.
Keep in mind, the acceptance of Lea’s proposal into the CSS spec got here as her birthday reward from the universe, so it’s not honest to attempt to exchange her reward with a kind of low cost pretend containers I purchased on Temu. She deserves an genuine container.
Let’s attempt once more.
Busting out the gangsta wrapper
One of many feedback on Lea’s proposal mentions kind grinding however calls it “a very (I repeat, very) convoluted however working” strategy to fixing the issue that inline conditionals are meant to unravel. That’s not fairly honest. Sort grinding took me a bit to get my head round, however I feel it’s extra approachable with fewer drawbacks than different hacks. Nonetheless, whenever you take a look at the samples, this sort of code in manufacturing would get annoying. Due to this fact, let’s chunk the bullet and attempt to construct an alternate model of Lea’s flexbox variant pattern. My model doesn’t use kind grinding or any hack, however “plain previous” (not so previous) type queries along with wrapper divs, to work round the issue that we are able to’t use type queries to type the container itself.
The wrapper battles kind grinding
Evaluating the code from Lea’s pattern and my model may also help us perceive the variations in complexity.
Listed below are the 2 variations of the CSS:
And listed here are the 2 variations of the markup:
So, less complicated CSS and barely extra markup. Possibly we’re onto one thing.
What I like about type queries is that Lea’s proposal makes use of the type() operate, so if and when her proposal makes it into browsers then migrating type queries to inline conditionals and eradicating the wrappers appears doable. This wouldn’t be a 2025 article if I didn’t point out that migrating this sort of code may very well be a viable use case for AI. And by the point we get inline conditionals, possibly AI received’t suck.
However we’re getting forward of ourselves. Have you ever ever tried to undertake some whizz-bang JavaScript framework that appears elegant within the “to-do listing” pattern? If that’s the case, you’ll know that options that seem compelling in simplistic examples can problem your will to stay in a practical instance. So, let’s see how utilizing type queries within the above method works out in a extra lifelike instance.
Searching for validation
Mix my above pattern with this MDN instance of HTML5 Validation and Seth Jeffery’s cool demo of morphing pure CSS icons, then feed all of it into the “What If” Machine to get the demo under.
All of the modifications you see to the callout should you make the shape legitimate are based mostly on one customized property. This property is rarely straight utilized in CSS property values for the callout however controls the type queries that set the callout’s border coloration, icon, background coloration, and content material. We set the --variant property on the .callout-wrapper stage. I’m setting it utilizing CSS, like this:
@property --variant success";
initial-value: error;
inherits: true;
physique:has(:invalid) .callout-wrapper {
--variant: error;
}
physique:not(:has(:invalid)) .callout-wrapper {
--variant: success;
}Nevertheless, the variable may very well be set by JavaScript or an inline type within the HTML, like Lea’s samples. Kind validation is simply my method of constructing the demo extra interactive to point out that the callout can change dynamically based mostly on --variant.
Wrapping up
It’s off-brand for me to write down an article advocating towards hacks that bend CSS to our will, and I’m all for “tricking” the language into doing what we wish. However utilizing wrappers with type queries is perhaps the best factor that works until we get help for inline conditionals. If we wish to really feel extra like we live sooner or later, we might use the above strategy as a foundation for a polyfill for inline conditionals, or some preprocessor magic utilizing one thing like a Parcel plugin or a PostCSS plugin — however my set off finger will at all times itch for the Delete key on such compromises. Lea acknowledges, “If you are able to do one thing with type queries, by all means, use type queries — they’re nearly actually a greater answer.”
I’ve satisfied myself with the experiments on this article that type queries stay a cromulent possibility even in Lea’s motivating examples — however I nonetheless stay up for inline conditionals. Within the meantime, not less than type queries are simple to grasp in comparison with the opposite identified workarounds. Sarcastically, I agree with the feedback questioning the necessity for the inline conditionals function, not as a result of it should damage CSS however as a result of I consider we are able to already obtain Lea’s examples with present fashionable CSS and with out hacks. So, we might not want inline conditionals, however they may permit us to write down extra readable, succinct code. Let me know within the remark part should you can consider examples the place we might hit a brick wall of complexity utilizing type queries as an alternative of inline conditionals.
