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...
The paths of least resistance on the web are now very different. These features were not delayed due to implementation details, but a deliberate shepherding of the standards. The most powerful features were saved for later and even still this is scoped to media queries, etc. only.
And, maybe, in a TTF font.
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.
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
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.
1: https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
So in that sense CSS + HTML + User Interaction is Turing complete. But that is a different language then CSS, even if a part of that language happens to be written in CSS.
EDIT: For the record, while I am very impressed, and this is a wonderful work of art we can all enjoy, I am not convinced this is proof of the Turing completeness of CSS. At most this would prove that CSS + HTML is Turing complete (which still better then CSS + HTML + User instructions in natural language). But I wonder if in these 43000 lines of CSS the entire state space was encoded (with some clever compression obviously), and I am not sure if that would count as proof of Turing completeness.
CSS alone is not Turing-complete (AFAIK), because you don't have anywhere to attach state (the computed style) if you don't have a DOM and loops are generally prohibited. But CSS exists literally only to style a DOM, so I don't consider that all that much of a concession.
Although I feel like we've already explored this with XSL. The XML syntax was perhaps too much to swallow.
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 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.
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.
Disagree. The newer stuff is, if anything, more confusing. The old stuff, awful as it was, at least had a consistent model.
With the "old stuff", we didn't a layout model or an alignment model. Everything required float and positioning hacks to do things they weren't designed to do. There's no logical way that was "better."
There were several different grid systems, all mostly incompatible with each other, which were required to do anything interesting.
Many layouts that are common today were impossible to do with just HTML & CSS back in '90s and 2000's.
Capabilities that almost all developers had to reach for a framework Bootstrap or Foundation for are built-in to CSS today. Or lots of JavaScript.
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.
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...
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.
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.
This distinction never existed in LISP. Greenspun's tenth rule in action.
- 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.
I guess the answer to your question is OCaml has unmanaged side effects.
Ant came first, then when Microsoft redid the VS project format, they created MSBuild.
As incredible as it may sound, Ant is still easier to deal with than MSBuild.
If you understood the paradigm, you could write branches in Ant files simply using properties and guards on properties ("unless"). Using IF in Ant was basically admission of not having understood Ant.
This said, I used Ant for a very limited amount of time.
https://ant.apache.org/manual/Tasks/condition.html
The else part is easily done by repeating and negating the condition.
Two other advantages of Ant that MSBuild lacks in a sane way to this day, are macros, and proper documentation.
I always liked Ant, as I don't suffer from XML allergy.
Also you forgot MSBuild is used for everything, not only .NET.
Never seen any big corp using alternative .NET build tools, rather wrestling MSBuild, or before it came to be, nmake.
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"?
This is not necessarily a problem except that they had to live in the original HCL v1 landscape which makes them awkward syntactically.
... What? How is modules a function call? It's just a hierarchy, everything about/with modules is still declarative.
> HCL 2 has loops and conditionals. It is most definitely imperative.
So what? Just because there is loops and conditionals doesn't mean it's suddenly imperative.
How exactly you do loops in HCL? Last time I used it, you still used declarative configuration for that, and use `for_each` as an declared option, you don't "call for_each which returns config", all that happens inside of HCL/TF, because it is declarative.
Did something change like yesterday or are people even here on HN so ignorant about what declarative vs imperative actually means?
I don't understand why there is a distinction between for each in a standard language vs for_each in HCL2. They are both do something by iterating over something else at runtime. The syntax isn't what matters here.
I think maybe you are mistaken in your own distinction between declarative and imperative.
Declarative: Tell the computer what you want the result to be like, and the computer figures out how to do it.
for_each in Terraform is very much declarative, just like modules. Compare how you'd do the same thing with JS or any other (imperative) language you know, and I think it must be clear what the difference between the two is.
I have read terraform modules where I had to execute the logic to know what got produced which moves it from your imperative description to the declarative description as far as I'm concerned.
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.
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.
https://mikehadlow.blogspot.com/2012/05/configuration-comple...
A programming (i.e Turing complete) language requires recursion or a construct of equal power.
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.
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>
Fun way of having a conversation.
The question still is: why is CSS becoming a programming language? And who decides on this, anyway?
I mean looking at the mdn docs it's just a replacement for regular other syntax https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...
So instead of having a css for x which defines e.g. dark mode and light mode separately, you can now define it via a single css rule.
Where previously the "tree" forked at the beginning and attributes were set multiple times, depending on various criteria - now you set it once, and evaluate it's value depending on criteria
div {
background-image: if(
style(--scheme: ice): linear-gradient(#caf0f8, white, #caf0f8);
style(--scheme: fire): linear-gradient(#ffc971, white, #ffc971);
else: none;
);
}
But instead of a single unified standard library for the industry we got a sprawling, ludicrous mess of multiple poorly thought-out semi-compatible technologies, with an associated sub-industry of half-baked fixes and add-ons.
I'm glad the transition to mobile web accelerated on more battery efficient GPUs was possible due to the model instead of Alan Kay's idea that websites should render themselves, where each website would have needed to be upgraded for GPU support for compositing.
The context is also lost. Javascript was famously coded in a day or whatever and called 'javascript' not ecmascript as marketing to compete with Java. Besides that well known case there's presumably thousands of esoteric business decisions made back then which shaped the "sprawling, ludicrous" landscape, and which are now lost to time.
Yes, the web should have always been a programming language. And the flying cars of 23xx should have never used a z-debuffer doodad.
Why? Because of enormous JS bloat. Pure CSS solutions are more performant and backwards-compatible (don't raise exceptions which abort the code).
Who decides? CSS Working Group.
Efficient evaluation of expressions is a solved problem.
Having conditionals would actually improve performance because you can use fewer rules.
What I see in the SO answer is an interface for Rule 110 with an additional set of instruction (written in a natural language) for the user to execute manually. So you can use CSS + HTML to create an interface for a Rule 110, which is then written in a natural language around that interface. The answer even states that (very relevant) caveat.
> [...] so long as you consider an appropriate accompanying HTML file and user interactions to be part of the “execution” of CSS.
> The formal definition (simplest) of Turing Machine is simply a tuple of states set, symbol set, initial state, accepting states set and a transition function. There is no crank in it. By computation we mean somebody needs to apply the transition function faithfully on the tape which is exactly like the clicking in this case. More formally, a model of computation can be viewed as a set of rules somebody needs to follow to do the computation. In that sense, I think CSS is Turing-Complete.
There is even a "CPU emulation" in pure CSS: https://dev.to/janeori/expert-css-the-cpu-hack-4ddj and pure CSS fetch: https://dev.to/janeori/100-css-fetch-and-exfiltrate-512-bits...
What stops newcomers is knee-jerk reactions about the (lack of) syntax, it's scary to see something that doesn't look like Algol, because everyone who does mainstream programming uses Algol-like languages.
Introduce lisp to anyone who knows programming since earlier, and 99% of them will have a adverse reaction to s-expressions, before they understand what's going on. Once they understand, it makes a lot of sense obviously, but not everyone even has that kind of open mindset where they could understand if they wanted to.
I'm not sure that's true. Because Lisp has a lot of facilities for writing more concise code that are difficult to achieve without the parens.
You've almost convinced/nerd-sniped me to write a(nother) new lisp where we'll be using brackets for forms and lists and no parenthesis in sight. It's a wild theory.
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...
"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.
i want better, declarative, interactive, fast UIs
CSS is the best answer we have
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".
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.
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.
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 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.
> All major browser engines are working on implementing this spec.
However their official positions are absent:
https://github.com/mozilla/standards-positions/issues/1167
https://github.com/WebKit/standards-positions/issues/453
And Firefox’s bug for implementing it has no activity:
https://bugzilla.mozilla.org/show_bug.cgi?id=1981485
And Can I Use’s underlying data doesn’t have this note:
https://github.com/Fyrd/caniuse/blob/fedfb067aceccb2a5edadcc...
So it’s unclear why the Can I Use website is saying that everybody is working on it.
Sorry but if you use advanced feature and especially on a big DOM, you have to think about optimisations.
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.
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.
(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."
You're right, the entire Values section seems to still be worded exclusively for flexboxes. The description at the top adds "or a grid or block-level element's block axis".
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>
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.
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.
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.
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.
aanthonymax•2mo ago