Geoff’s submit concerning the CSS Working Group’s resolution to work on inline conditionals impressed some drama within the feedback part. Some builders are excited, nevertheless it angers others, who worry it can make the way forward for CSS, properly, 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 secure.
You say the entire world’s ending — honey, it already did
My thesis for at this time’s article provides additional reassurance that inline conditionals are in all probability not the harbinger of the tip of civilization: I reckon we are able to obtain the identical performance proper now with fashion queries, that are gaining fairly good browser assist.
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 all the time been conditional. Not that conditionality was ever verboten in CSS, however CSS isn’t all the time superb at it.
Bought! I desire a conditional oompa loompa now!
Me too. And lots of different individuals, as confirmed by Lea’s curated checklist 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 uncertain if I perceive them, however they actually have cool names. Lea concludes: “For those who’re conscious of some other methods, let me know so I can add them.”
Hmm… absolutely I used to be lacking one thing concerning the issues these hacks resolve. 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 individuals doing all this work to keep away from placing an additional div round their widgets and utilizing fashion queries?
It’s truthful if individuals wish to keep away from superfluous components within the DOM, however Lea’s checklist of hacks exhibits that the alternate options are tremendous complicated, so it’s price a shot to see how far fashion 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 virtually obtain what she needs with fashion queries, however this hypothetical syntax is unfortunately invalid:
.callout {
@container (fashion(--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 present the phantasm that it’s the container. Then I might fashion 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 shouldn’t be 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 truthful to attempt to exchange her reward with a type of low-cost pretend containers I purchased on Temu. She deserves an genuine container.
Let’s strive once more.
Busting out the gangsta wrapper
One of many feedback on Lea’s proposal mentions sort grinding however calls it “a very (I repeat, very) convoluted however working” strategy to fixing the issue that inline conditionals are supposed to unravel. That’s not fairly truthful. Sort grinding took me a bit to get my head round, however I believe it’s extra approachable with fewer drawbacks than different hacks. Nonetheless, if you have a look at the samples, this type 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 sort grinding or any hack, however “plain previous” (not so previous) fashion queries along with wrapper divs, to work round the issue that we are able to’t use fashion queries to fashion the container itself.
The wrapper battles sort grinding
Evaluating the code from Lea’s pattern and my model may help 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. Possibly we’re onto one thing.
What I like about fashion queries is that Lea’s proposal makes use of the fashion() perform, so if and when her proposal makes it into browsers then migrating fashion 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 checklist” pattern? If that’s the case, you’ll know that options that seem compelling in simplistic examples can problem your will to reside in a sensible instance. So, let’s see how utilizing fashion queries within the above method works out in a extra lifelike instance.
In search of 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 beneath.
All of the modifications you see to the callout in case you make the shape legitimate are based mostly on one customized property. This property is rarely immediately utilized in CSS property values for the callout however controls the fashion 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 fashion within the HTML, like Lea’s samples. Type validation is simply my means of creating 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 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 fashion queries is perhaps 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 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 all the time itch for the Delete key on such compromises. Lea acknowledges, “If you are able to do one thing with fashion queries, by all means, use fashion queries — they’re virtually actually a greater answer.”
I’ve satisfied myself with the experiments on this article that fashion queries stay a cromulent possibility even in Lea’s motivating examples — however I nonetheless look ahead to inline conditionals. Within the meantime, not less than fashion queries are simple to grasp in comparison with the opposite recognized workarounds. Paradoxically, I agree with the feedback questioning the necessity for the inline conditionals function, not as a result of it can damage CSS however as a result of I imagine 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 might permit us to put in writing extra readable, succinct code. Let me know within the remark part in case you can consider examples the place we might hit a brick wall of complexity utilizing fashion queries as a substitute of inline conditionals.
