The What If Machine: Bringing the “Iffy” Way forward for CSS into the Current

Geoff’s submit in regards to the CSS Working Group’s determination to work on inline conditionals impressed some drama within the feedback part. Some builders are excited, but it surely angers others, who concern it should 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. 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 in the present day’s article provides 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 type queries, that are gaining fairly good browser assist.

If I’m proper, Lea’s proposal is extra like syntactic sugar which might generally 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, “Similar to ternaries in JS, it might 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 superb at it.

Bought! I need a conditional oompa loompa now!

Me too. And plenty of different individuals, as confirmed by Lea’s curated checklist of amazingly complicated hacks that individuals have found for simulating inline conditionals with present CSS. A few of these hacks are difficult sufficient that I’m nonetheless not sure if I perceive them, however they actually have cool names. Lea concludes: “In the event you’re conscious of another strategies, let me know so I can add them.”

Hmm… absolutely 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 individuals doing all this work to keep away from placing an additional div round their widgets and utilizing type queries?

It’s truthful if individuals wish to keep away from superfluous parts 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 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);
      coloration: var(--color-success-05);
    }
  }
}

She desires 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 type the borders and background of that. Sadly, this answer is as fragile as my ego, and in this different motivating instance, Lea desires to set flex-flow of the container based mostly on the variant. In that scenario, my pseudo-element answer is just not ok.

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 change 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 kind grinding however calls it “a very (I repeat, very) convoluted however working” strategy 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 believe 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. Subsequently, let’s chew 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 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 kind grinding

Evaluating the code from Lea’s pattern and my model might help us perceive the variations in complexity.

Listed below are the 2 variations of the CSS:

And listed below 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 might 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 practical 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 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 if you happen to 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 might be set by JavaScript or an inline type within the HTML, like Lea’s samples. Type validation is simply my approach of constructing the demo extra interactive to indicate that the callout can change dynamically based mostly on --variant.

Wrapping up

It’s off-brand for me to jot down an article advocating in opposition to hacks that bend CSS to our will, and I’m all for “tricking” the language into doing what we would like. 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 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 choice even in Lea’s motivating examples — however I nonetheless stay up for inline conditionals. Within the meantime, a minimum of type queries are straightforward to know in comparison with the opposite identified workarounds. Paradoxically, 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 imagine we are able to already obtain Lea’s examples with present fashionable CSS and with out hacks. So, we could not want inline conditionals, however they may enable us to jot down extra readable, succinct code. Let me know within the remark part if you happen to can consider examples the place we might hit a brick wall of complexity utilizing type queries as an alternative of inline conditionals.

---

The What If Machine: Bringing the “Iffy” Way forward for CSS into the Current initially printed on CSS-Tips, which is a part of the DigitalOcean household. It is best to get the e-newsletter.