Geoff’s post in regards to the CSS Working Group’s choice to work on inline conditionals impressed some drama within the feedback part. Some builders are excited, nevertheless it angers others, who worry it is going to make the way forward for CSS, nicely, 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 around putting crazy logic into CSS for the sake of it. Subsequently, 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 presents additional reassurance that inline conditionals are in all probability not the harbinger of the top of civilization: I reckon we are able to obtain the identical performance proper now with style queries, that are gaining pretty good browser support.
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 likely to be equal to catastrophizing including a ternary operator for a language that already helps if statements.
Certainly, Lea says of her proposed syntax, “Identical to ternaries in JS, it could even be extra ergonomic for circumstances 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 excellent at it.
Bought! I desire a conditional oompa loompa now!
Me too. And plenty of different folks, as confirmed by Lea’s curated listing of amazingly complex hacks that individuals have found for simulating inline conditionals with present CSS. A few of these hacks are difficult sufficient that I’m nonetheless uncertain if I perceive them, however they actually have cool names. Lea concludes: “If you happen to’re conscious of every other methods, let me know so I can add them.”
Hmm… certainly I used to be lacking one thing concerning the issues these hacks remedy. I famous that Lea has a doctorate whereas I’m an fool. So I scrolled again up and reread, however I couldn’t cease pondering: Are these folks doing all this work to keep away from placing an additional div round their widgets and utilizing type queries?
It’s truthful if folks wish to keep away from superfluous components within the DOM, however Lea’s listing of hacks exhibits that the 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 desires 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);
shade: var(--color-success-05);
}
}
}She desires to set kinds on each the container itself and its descendants primarily based 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 other motivating example, Lea desires to set flex-flow of the container primarily based on the variant. In that scenario, my pseudo-element answer isn’t adequate.
Bear in mind, the acceptance of Lea’s proposal into the CSS spec got here as her birthday present from the universe, so it’s not truthful to attempt to exchange her present with a kind of low cost faux containers I purchased on Temu. She deserves an genuine container.
Let’s attempt once more.
Busting out the gangsta wrapper
One of the comments on Lea’s proposal mentions type grinding however calls it “a very (I repeat, very) convoluted however working” method to fixing the issue that inline conditionals are meant to resolve. That’s not fairly truthful. Kind 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 have a look at the samples, this type of code in manufacturing would get annoying. Subsequently, let’s chew the bullet and attempt to construct an alternate model of Lea’s flexbox variant sample. My model doesn’t use sort grinding or any hack, however “plain outdated” (not so outdated) 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 sort grinding
Evaluating the code from Lea’s pattern and my model can assist us perceive the variations in complexity.
Listed here 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. Perhaps we’re onto one thing.
What I like about type queries is that Lea’s proposal makes use of the type() perform, 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 type of code may very well be a viable use case for AI. And by the point we get inline conditionals, possibly AI gained’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? In that case, you’ll know that options that seem compelling in simplistic examples can problem your will to dwell in a sensible instance. So, let’s see how utilizing type queries within the above method works out in a extra reasonable instance.
Looking for validation
Mix my above pattern with this MDN example 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 beneath.
All of the adjustments you see to the callout in the event you make the shape legitimate are primarily based on one customized property. This property is rarely instantly utilized in CSS property values for the callout however controls the type queries that set the callout’s border shade, icon, background shade, and content material. We set the --variant property on the .callout-wrapper degree. 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;
}Nonetheless, 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 creating the demo extra interactive to point out that the callout can change dynamically primarily based on --variant.
Wrapping up
It’s off-brand for me to put in writing 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 likely to be the best factor that works until we get assist for inline conditionals. If we wish to really feel extra like we live sooner or later, we might use the above method 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 choice even in Lea’s motivating examples — however I nonetheless sit up for inline conditionals. Within the meantime, no less than type queries are simple to know 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 is going to spoil 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 put in writing extra readable, succinct code. Let me know within the remark part in the event you can consider examples the place we might hit a brick wall of complexity utilizing type queries as a substitute of inline conditionals.
