CSS now has an if() conditional function
caniuse.com132 points by aanthonymax 5 days ago
132 points by aanthonymax 5 days ago
Give it enough time, every declarative language becomes a programming language. This is happening with all config files, markup languages, data formats.
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.
We can blame von Neumann (et al) and his infernal architecture, where memory stores both instructions and data.
You can blame whoever invented the word "if", as soon as you can branch based on data you can just write an interpreter that turns data into instructions, no matter the architecture.
Not really, most of these configuration as code systems are not executed directly on the CPU but rather interpreted in which case a separate data-only memory would not stop anyone.
von Neumann did not invent the von Neumann architecture. Not even a little bit.
If you want to reason that the hardware is at fault, you should be blaming the Eckert-Mauchley architecture.
This is so true, I have seen it happen with so many projects. It always starts with a cute declarative DSL, and inevitably imperative / flow control structures emerge, at which point you wonder why they didn't use a real programming language in the first place and save you the hassle or learning a half baked imperative DSL.
- Puppet
- CMake
- Terraform
- ...
All these started with pure declarative DSL then incrementally created a nightmarish imperative monstrosity.
- Visual Studio project files are XML files that are interpreted line by line, and can contain variables, branches, and loops. Hell on earth.
what's even worse that schema uses extremely generic types with attributes denoting actual type.
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.
> The distinction between code, config and data is being erased.
This distinction never existed in LISP. Greenspun's tenth rule in action.
So why do people still design declarative languages?
Wishful thinking? Maybe they are tired of all this and want to make something good again, and so the cycle continues.
I'm pretty happy to see this, as conditionals can really help keep code manageable when trying to define CSS variables or other properties based on combinations of light mode, dark mode, high-contrast, contextual state in a document or component, etc.
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.
Far from being ready when only one major browser supports it. If you want this, you should vote for it to be focused on for interop-2026
https://github.com/web-platform-tests/interop/issues
Right now, the leading CSS proposals are `@container style()`, `corner-shape` and `break-after`
Yeesh.. I've definitely tried using break-after and being disappointed it didn't work properly. The amount of hoops I had to jump through to get things to print properly on paper...
Can it already vertically and horizontally center unknown-beforehand-length multi-line text in a single html element, just like non-CSS table cells could already in 1995?
As long as css remains "so fast it's free" then I'm mostly happy with that - I use css without thinking about optimisations, and I like it like that!
You can certainly write slow CSS, and people do :-) JavaScript typically takes up more of the CPU time overall, though.
It's not free at all. You can profile it with debug tools and find the most expensive selectors to refactor them. You can also write CSS animations that impacts performance/user experience, this can also be profiled.
Sorry but if you use advanced feature and especially on a big DOM, you have to think about optimisations.
It's a great way to make conditional styles without having to use JavaScript; however, having used JS for years to make theme color and icon sets that rely on CSS properties, I'm not sure I particularly like this method. I feel like you have to smear a lot of logic across your CSS whereas with JS you can reduce your theme to a data structure and just have a simple function to setup all the CSS variables based on that.
Am I just an old man?
The primary goal is to just have a more concise way to do @media queries. Its not intended as a replacement for most uses of JS
If we've learned anything from the history of CSS, JS and the semantic web it is that 99% of the time a feature will be used in ways that were not intended. There is no reason to suppose that this will be any different.
Javascript always suffer from FOUC problem though (Unless it's server side). Although the if() css function seems to just be syntax suger of standard @media query. So it doesn't really add anything to solve existing problems.
Edited: It seems it can also be toggled from css variable? So it might actually fix some existing problems.
How hard would it be to have a response header that tells the browser "don't display anything at all until we ask you to from JS when we're ready"?
Considering the kinds of crap that have been done with headers...
Many sites do something like that in practice. The problem is the extra 500ms of parse+eval time for your JS bundle influences user behavior a lot on the margin, so it’s better to not force the user to wait.
Would it be enough to have <body> hidden using an inline style in the initial html response and when everything is loaded, one would remove the style using javascript?
How hard would it be to use JS for progressive enhancement instead making your website depend on it to display simple text and images.
Practically only cordova does these for now. But it's a native app so of course it can do whatever it want.
I like making static informational pages and don't know the first thing about JavaScript, so this could be handy for me.
So we were looking in the wrong direction for AGI!
Replying to myself (hey, I like myself and I'd like to have a conversation with me):
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?
Nice. I've built desktop apps in a few other frameworks e.g. Java Swing, JavaFX, JetBrains Compose, SwiftUI, QT. Nothing is as easy as JS/HTML/CSS. I've realized that the main reason is its robust capabilities e.g rich auto-layouting/positioning capabilities.
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'm not sure turning CSS into a full blown language is a good idea. With all the cascading in place, it is already a bit hard to determine why certain styles are applied. Now with this, we will be spending more brain cells debugging CSS issues.
On the contrary, a lot of the reason CSS is confusing is because it's full of insane hacks people have to do to get the behaviour they want. A straight-up if statement is much simpler than many of the horrors I've seen.
css definitely shouldn't have backwards branches (loops/recursive functions), but adding a little more power can clean up expression a ton and make reading/applying that much faster
I wish the "little more power" would add CSS modules. It would also be great if web components didn't require Javascript and could be configured with pure HTML and 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.
Here is a much better link to how it works: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...
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".
With the inclusion of branches, is it possible to say that CSS is now even more Turing-Complete? Now we just need to find ways to do recursion/targeted jumps so that it is finally recursive-enumerable
Somewhere, someone has just started porting Doom to CSS.
If we could do it over, knowing that we'd eventually get to this point, would https://en.wikipedia.org/wiki/JavaScript_Style_Sheets have been the better path?
I would say no. I think CSS is a good language and made good choices.
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.
I actually wonder if transpiling calc/min/max/etc. expressions to JS is a viable path to implementation, considering that you already need a fast interpreter for these.
If I had a time machine I would go back and ensure that DSSSL (https://en.wikipedia.org/wiki/Document_Style_Semantics_and_S...) was the standard that got up.
All hail the embedded Scheme interpreter to apply Style transformations!
Although I feel like we've already explored this with XSL. The XML syntax was perhaps too much to swallow.
You write your markup in an xml syntax, your scripts in a C syntax, and your styles in a lisp syntax... a perfect trio.
Probably not. There is a lot of optimizations browsers do to make the stylesheets super fast[1], and I think quite a few of those rely on CSS not being Turing complete.
1: https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
CSS is Turing complete :-) You can find pure-CSS implementations of Game of Life, for instance.
If I'm reading this correctly, Opera added support in an earlier version then took it away again. Any idea why they might have done it? Maybe a browser engine change under the hood?
It's a working draft and only available in Chromium ...
I'm not really sure I understand this. How is the new if() conditional function different from using @media (width ...) when adapting layouts to browser width?
Its basically the same, just more convinent syntax.
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 missing a "if variable equals" imho. Right now it seems like pure syntactic sugar for a media query.
>This is missing a "if variable equals" imho.
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.
Did you guys read the docs? It literally does have this albeit the syntax is a bit odd:
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...
Can these be used inside inline style attributes?
Not supported in Firefox and Safari. Also it seems most people forget that the more bloated the web platform is, the more resources are needed to develop and maintain a web browser engine.. Chromium is open-source, but it's already expensive to maintain a fork or even rebuild it..
They just need to start deprecating and removing old features. They had no issues with XSLT removal even when some major sites like the library of congress used it. So the excuse of backward compatability has already proven to be a lie.
[flagged]
> How did this happen?
That's pretty simple - Google has poured tons of money into Chrome and Mozilla. Google is not a charity so this was a strategic investment.
> You should go over to the CSS working group and let them know
That wouldn't work, money is what ultimately matters there.
[flagged]
lol. What other browser vendors? Whatwg is just google is a trench coat. Edge is chrome. Firefox is funded by Google. So I guess apple who's main contribution is being years behind and having half their stuff be broken
There's this really cool site where you can see how well supported a feature is: https://caniuse.com/?search=if
If Google controls everything, why is if() only supported on 59% traffic? Do you think any serious company will let their site break on 40% of clients? Do you think Apple's opinion is unimportant?
Did you look at detailed usage stats? More specifically at things that do not count towards that 59%: older versions of Chrome add another 20%, various Chromium forks add a few percent more, so the rest of the internet accounts for less than 20%. I'd say this is pretty monopolistic for one company to control the means of more than 80% of traffic of doing its 'trafficking'.
> And the other browser vendors with conflicitng interests just go along with it?
When there's a conflict of interest they don't (Apple refuses to implement some APIs that would help making their walled garden app store more obsolete). But just maintaining a duopoly (Mozilla is funded by Google) is not a conflicting interest itself.
> Did you come to that opinion after engaging in the discussions with them?
With employees? There's no point. If you have a well paid job you will never accept the fact that what you're doing might not be so good after all..
> When there's a conflict of interest they don't (Apple refuses to implement some APIs that would help making their walled garden app store more obsolete). But just maintaining a duopoly (Mozilla is funded by Google) is not a conflicting interest itself.
What makes you think Apple wants to maintain any sort of duopoly? Do you think they're happy that Edge became a Chrome skin?
> With employees? There's no point. If you have a well paid job you will never accept the fact that what you're doing might not be so good after all..
Damn, so you haven't even tried discussing your issues with the people responsible? You seem to have a really strong opinion on something you haven't engaged with at all.
This support has appeared in the new W3C specification.
[dead]