The distinction between code, config and data is being erased. Everything is a soup now. Data is application, configuration is code. Code is an intermediate, volatile thing that is generated on the fly and executed in the temporary lambda containers.
If you want to reason that the hardware is at fault, you should be blaming the Eckert-Mauchley architecture.
- Puppet
- CMake
- Terraform
- ...
All these started with pure declarative DSL then incrementally created a nightmarish imperative monstrosity.
Makes reading it even harder, and any possible constraints due to type safety go out of the window, so we get worst of both worlds.
This distinction never existed in LISP. Greenspun's tenth rule in action.
if() isn't the only way to do this, though. We've been using a technique in Review Board that's roughly equivalent to if(), but compatible with any browser supporting CSS variables. It involves:
1. Defining your conditions based on selectors/media queries (say, a dark mode media selector, light mode, some data attribute on a component, etc.).
2. Defining a set of related CSS variables within those to mark which are TRUE (using an empty value) and which are FALSE (`initial`).
3. Using those CSS variables with fallback syntax to choose a value based on which is TRUE (using `var(--my-state, fallback)` syntax).
I wrote about it all here, with a handful of working examples: https://chipx86.blog/2025/08/08/what-if-using-conditional-cs...
Also includes a comparison between if() and this approach, so you can more easily get a sense of how they both work.
https://github.com/web-platform-tests/interop/issues
Right now, the leading CSS proposals are `@container style()`, `corner-shape` and `break-after`
Sorry but if you use advanced feature and especially on a big DOM, you have to think about optimisations.
CSS doesn't have it right? Just Chrome.
Considering how all kinds of "experts" have started to make web sites that only work fine in Chrome [1], this is not exactly a useful new feature, more like embrace and extend...
[1] Orange Romania, when will I be able to download my invoices again in Firefox?
Am I just an old man?
Edited: It seems it can also be toggled from css variable? So it might actually fix some existing problems.
Considering the kinds of crap that have been done with headers...
Meanwhile in other UI frameworks, you either don't do it or you draw the damn things yourself lol. So, most of the times I'd just not do it.
Adding if is great. It would reduce the need for JS a bit more, which would make the code more maintainable.
I will kiss the feet of the whatwg groups if they do this.
PS: Would also love to have declarative template inclusion now that removal of XSLT has also removed this facility from the browser.
padding: 1em;
padding: if(style(--size: "2xl"): 1em; else: 0.25em);
This is counterintuitive. You would expect the above falls back to "1em" (from "padding: 1em") when "else" is not specified. Instead, omitting "else" apparently means "else: initial".
And honestly we already essentially have this with CSS related apis in js. The examples in that article are basically identical to how you set css in js on modern web browsers with slightly different naming conventions.
Although I feel like we've already explored this with XSL. The XML syntax was perhaps too much to swallow.
1: https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
I think if can also do string equality on variable values, which is a bit new but also niche. The main point is just to do @media but inside a property decleration.
This is exactly what it does not need. SASS style conditional CSS is a complete nightmare to maintain. The declarative nature is one of its greatest strengths.
if(style(--foo: bar): baz)
Is how you test if variable --foo is equal to "bar"
See https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...