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.
Overly pessimistic, lots of non-programming languages remain non-programming languages. Just because one of the most widely used declarative languages start adding conditionals doesn't mean the whole world is turning upside down...
> The distinction between code, config and data is being erased.
As as lisp programmer, I love it. Get rid of treating things differently, make everything the same and make everything work with everything, code should just be data.
"Code should just be data" doesn't imply the converse, though; there's arguably utility in having data that isn't code, even with the premise that code should be data.
The question still is: why is CSS becoming a programming language? And who decides on this, anyway?
if() just codifies behaviors and hacks [1] developers were already doing.
[1]: https://lea.verou.me/blog/2020/10/the-var-space-hack-to-togg...
You need to look at a large terraform project.
> As as lisp programmer, I love it.
You make bad engineering decisions because you consider the advantages, but not the disadvantages. <https://news.ycombinator.com/item?id=29231493>
- Puppet
- CMake
- Terraform
- ...
All these started with pure declarative DSL then incrementally created a nightmarish imperative monstrosity.
CMake today is effectively an eso-lang / Turing tarpit with some “modern” declarative conventions that people try to push.
"Huh?" I asked myself when you mentioned that Terraform is now imperative somehow. Took a look at the website again, and seems to still be HCL, and still be declarative. Am I missing something? How exactly is Terraform today a "imperative monstrosity"?
A programming (i.e Turing complete) language requires recursion or a construct of equal power.
This distinction never existed in LISP. Greenspun's tenth rule in action.
CSS already has all sorts of conditionals that are if() in disguise!
For instance a selector like .foo means "if the class is foo then select this style block'.
CSS is thoroughly condition-driven already.
https://en.wikipedia.org/wiki/Harvard_architecture
That said, I'm unaware of any programming language (outside assembler) that takes that split to heart in a higher-level way.
If you want to reason that the hardware is at fault, you should be blaming the Eckert-Mauchley architecture.
It is a configuration language with general programming features, but it is decidedly _not_ Turing complete. It seems to sit at a sweet spot between "just JSON, no programming convenience at all" and "full-blown programming language with nontrivial toolchain".
It's not that the presentation layer need conditionals, it's that the layers under it have grown full of hacks that need more hacks to work around them, because the web was designed to grow documents, not programs.
If the web had been designed for applications in the first place, the presentation layer probably wouldn't need conditionals at all.
https://mikehadlow.blogspot.com/2012/05/configuration-comple...
Cost.
If money were no object, you would only hire people who can troubleshoot the entire stack, from React and SQL all the way down to machine code and using an oscilloscope to test network and power cabling.
Or put another way, it would be nice for the employer if your data analyst who knows SQL also knew C and how to compile Postgres from scratch, so they could fully debug why their query doesn’t do what they expect. But that’s a more expensive luxury.
Good software has declarative and imperative parts. It’s an eternal tradeoff whether you want the convenience of those parts being in the same codebase, which makes it easier to troubleshoot more of the stack, but that leads to hacks that break the separation. So sometimes you want a firm boundary, so people don’t do workarounds, and because then you can hire cheaper people who only need to know SQL or React or CSS or whatever, instead of all of them.
Then time passes, edge cases start cropping up and hacks are bolted on to accommodate them. Eventually everything struggles under the weight of not having loops, conditionals, etc. and those are added.
After some time, the cycle begins anew.
i want better, declarative, interactive, fast UIs
CSS is the best answer we have
https://github.com/web-platform-tests/interop/issues
Right now, the leading CSS proposals are `@container style()`, `corner-shape` and `break-after`
Anybody know how that compares to Report Definition Language?
https://learn.microsoft.com/en-us/sql/reporting-services/rep...
Seems like an awfully scattered shitshow just to arrive at a typical "What You See Is Not What You Get" result.
And this one is made for printouts.
Unfortunately the test set of wpt does not have the capability to cover printed matter so relief isn't coming any time soon
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.
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...
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".
padding: 1em;
padding: var(--padding);
padding: 1em;
@container style(--padding) {
padding: var(--padding);
}
@layer base {
padding: 1em;
}
@layer override {
padding: var(--padding, revert-layer);
}CSS is confusing because the vast majority of web developers never learned it properly. Many developers won't learn any "new" CSS (like CSS Grid which shipped in all browsers in 2017) beyond the hacks they learned in the '90s and early 2000's.
That's not the fault of CSS.
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.
1: https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
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.
That's not going to happen.
They can't break millions of websites by removing old features. Besides, for the most part, current developers can ignore most of the old stuff.
But a site made in 1997 has to render on current browsers.
CSS if() probably just merges one of two single-property RuleSets onto the parent RuleSet depending on the condition, which has nothing to do with branching, as there is no execution flow to branch.
And, maybe, in a TTF font.
The spec of flex layout requires it to layout its child elements several times to compute actual layout. Make it deep and nested without proper constrains will results in n*n*n*n… layout computations and bring down the browser on resize.
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?
I don't see Mozilla's or WebKit's positions anywhere, so this is a Chromium-only feature for now.
That's what happens when you design a language by comitee (C++, JS) and try to do stuff in the web for a platform made to share static documents.
Just look at what kind of disasters the users faced with Office macros.
Non-CSS table cells have never been able to do that – you need a wrapping <table> at minimum for browsers to render it how you want, a <tr> for it to be valid HTML, and <tbody> comes along for the ride as well as an implied element. So that’s four elements if you want to centre vertically with <td> or <th>. If you wait until the year 2000, then you can get that down to three elements by switching from HTML to XHTML because <tbody> is no longer implied in XHTML.
CSS, on the other hand, has been able to do what you want since 1998 (CSS 2) with only two elements:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<title>.</title>
<style type="text/css">
html,
body {
height: 100%;
}
.outer {
display: table;
width: 100%;
height: 100%;
}
.inner {
display: table-cell;
vertical-align: middle;
text-align: center;
}
</style>
<div class="outer">
<div class="inner">
Test<br>
Test<br>
Test<br>
Test<br>
Test<br>
Test
</div>
</div>
(supported on block elements since sometime last year)
That means I may finally not need line-height or multi-element tricks for this anymore
Interesting that this is finally there since a year!
I wonder what made them decide to support it finally, since CSS's creation in 1996.
A button never looks professional if the text in it isn't centered, this was a really needed feature and I still can't understand why it took that long
Edit: it does seem worrying that for me this property vertically centers but not horizontally while the description of it doesn't say vertical but is: "The items are packed flush to each other in the center of the alignment container along the cross axis."
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...
At the same time over a period of years the web approach is to make the whole thing more like a bunch of interlocked Excels, more so than it already was before.
Does that mean any resulting disadvantage during following years is intentional? Any more than huge orgs grew to depend on Excel, one physical desktop at a time since that was the only thing in common among all those diverse desk owners that would do the job, plus it was the first thing to come along to fill that niche.
And I used to defend and evangelize taking HTML&CSS seriously in my previous roles, which I'd still do!
But as much as I have longed for features like these in the past (also: :has(), container queries, custom properties...), I dislike this.
I found CSS grid disappointing for most use cases.
I think :has() is a terrible idea, except for quick hacks.
I still think container queries and custom properties are good.
But, oh well, old man yelling at cloud.
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.