Neat. But side note: do we really need if() in CSS? Like, the complexity that adds is going to be worth the functionality it brings? It's introducing a whole new paradigm to solve what real problem?
We already have specialized conditionals in CSS, such as @supports, minmax, media queries, etc.
if() is just a general purpose conditional.
Using if() is going to reduce complexity for a whole range of use cases. Right now, developers are using custom property hacks to simulate true conditionals [1].
I for one would much rather use local conditionals than do the logical equivalent through conditionally set CSS variables. It is much more readable and extendable than several layers of abstraction (design token vars -> semantic vars -> theme vars potentially complexed by media/container queries -> element styles).
Of course I wouldn’t replace all of that, but if() would certainly make many things easier to grok for the next guy. Just don’t overuse it.
JS is inherently single-threaded and mobile cores aren't really getting faster, but we are getting more of them. Allowing you to express more in CSS means you get faster-loading, more highly-performant, less energy-draining web UIs.
If we can introduce delay in the circuit it would be trivial to build FFs from Boolean-complete gate sets, thus sequential elements with memory. But AFAIK CSS if() can't introduce delays.
Basic arithmetic plus iteration is Turing complete. CSS has basic arithmetic but not iteration.
Some people have already claimed it's Turing complete by making the user hit tab and space to copy data between iterations, but I wouldn't listen to them. That copying role is simple but it's not negligible.
It lacks a usable form of pure-CSS recursion (which was intentionally excluded in this implementation) but that's not as big a problem as one would expect for a lot of practical things.
I’m going to assume this is a joke. However, if it’s not a joke, no. We as a community have gone to great lengths to use responsive design over the past few years. There are still styling cases for complex elements that can’t be implemented without JavaScript. This is just an additional step of the journey to allow intermediate styling for complex cases.
If anything, it should enable (minor) expansion of noscript!
Id actually like to redact that prior message and think further, here. We already have information egress thru URIs, with some amount of “protection” via CSP. But I didn’t think of other types of attack vectors at length. Someone above remarked that this is just a general form of conditional, which perhaps unlocks new vectors. Im always surprised by CSS so i should slow down and keep an open mind :)
I'm curious if you can accidentally make loops using some of these, and if there's some sort of settling/recursion limit.
EDIT: Apparently `style(..)` can only evaluate vars in this `if()`? It looks like `@container` is a way to manage generic style queries and that supports the full gamut of CSS queries.
A @container query does have some advantages — you
can only set single property values at a time with
if() style queries, whereas @container queries can
be used to conditionally apply whole sets of rules.
The two approaches are complementary, and have
different uses.
Note that container style queries currently don't
support regular CSS properties, just CSS custom
properties. For example, the following won't work: [..]
EDIT 2: OK, this required digging out the spec. They cannot cause recursion because of the substitution context rules:
For example, in --foo: if(style(--foo: bar): baz);
the style() query is automatically false, since
property replacement has already established a
«"property", "--foo"» substitution context. "
... and there are rules around cyclic evaluation in CSS:
When a cycle is detected, all participants in the cycle
become invalid. For example, all of the following
declarations become invalid at computed-value time."
Soon it’ll be shift registers, ALUs, and before we know it we’ll have DOOM in CSS.
Not exactly what you are asking for but we’re moving closer to your vision of the future:
https://github.com/yurkagon/Doom-Nukem-CSS
I'd prefer https://en.wikipedia.org/wiki/Wireworld
Neat. But side note: do we really need if() in CSS? Like, the complexity that adds is going to be worth the functionality it brings? It's introducing a whole new paradigm to solve what real problem?
We already have specialized conditionals in CSS, such as @supports, minmax, media queries, etc.
if() is just a general purpose conditional.
Using if() is going to reduce complexity for a whole range of use cases. Right now, developers are using custom property hacks to simulate true conditionals [1].
[1]: "The --var: ; hack to toggle multiple values with one custom property"—https://lea.verou.me/blog/2020/10/the-var-space-hack-to-togg...
See the MDN examples:
https://developer.mozilla.org/en-US/docs/Web/CSS/if
I for one would much rather use local conditionals than do the logical equivalent through conditionally set CSS variables. It is much more readable and extendable than several layers of abstraction (design token vars -> semantic vars -> theme vars potentially complexed by media/container queries -> element styles).
Of course I wouldn’t replace all of that, but if() would certainly make many things easier to grok for the next guy. Just don’t overuse it.
What in gods abomination is this - 3px yellow if( style(--color: green): dashed; style(--color: yellow): inset; else: solid; ) —-
CSS was suppose to be only for styles, single responsibility and all. What is the need to introduce logic in cascading style sheets. Isn’t js enough?
Different responsibilities.
if() seems great for multisite/multitheme enterprise applications.
JS is inherently single-threaded and mobile cores aren't really getting faster, but we are getting more of them. Allowing you to express more in CSS means you get faster-loading, more highly-performant, less energy-draining web UIs.
I assume this is not more powerful computationally than existing selectors, right? What exactly keeps CSS+HTML from being Turing-complete?
If you include the user clicking, then it already is. [0]
[0] https://github.com/brandondong/css-turing-machine
Nothing. Given infinite memory, a NAND gate is Turing complete by itself and trivial to construct based on the OP examples.
Unfortunately the examples provided by OP only contain combinational circuits, which by def. have no memory.
Well, there are half and full adders, maybe a flip-flop would be feasible?
If we can introduce delay in the circuit it would be trivial to build FFs from Boolean-complete gate sets, thus sequential elements with memory. But AFAIK CSS if() can't introduce delays.
Keyframe animation?
Basic arithmetic plus iteration is Turing complete. CSS has basic arithmetic but not iteration.
Some people have already claimed it's Turing complete by making the user hit tab and space to copy data between iterations, but I wouldn't listen to them. That copying role is simple but it's not negligible.
It lacks a usable form of pure-CSS recursion (which was intentionally excluded in this implementation) but that's not as big a problem as one would expect for a lot of practical things.
Ok, so NoScript should also block (parts of) CSS now, and not just JavaScript?
I’m going to assume this is a joke. However, if it’s not a joke, no. We as a community have gone to great lengths to use responsive design over the past few years. There are still styling cases for complex elements that can’t be implemented without JavaScript. This is just an additional step of the journey to allow intermediate styling for complex cases.
If anything, it should enable (minor) expansion of noscript!
Id actually like to redact that prior message and think further, here. We already have information egress thru URIs, with some amount of “protection” via CSP. But I didn’t think of other types of attack vectors at length. Someone above remarked that this is just a general form of conditional, which perhaps unlocks new vectors. Im always surprised by CSS so i should slow down and keep an open mind :)
I'm a little behind on my CSS, but apparently you can now evaluate styles in the container and act on them, at least in Chrome:
https://developer.chrome.com/blog/new-in-chrome-137
The example uses a newer `style(..)` condition I haven't seen yet:
https://developer.mozilla.org/en-US/docs/Web/CSS/@container#...
I'm curious if you can accidentally make loops using some of these, and if there's some sort of settling/recursion limit.
EDIT: Apparently `style(..)` can only evaluate vars in this `if()`? It looks like `@container` is a way to manage generic style queries and that supports the full gamut of CSS queries.
https://developer.mozilla.org/en-US/docs/Web/CSS/if
EDIT 2: OK, this required digging out the spec. They cannot cause recursion because of the substitution context rules:https://drafts.csswg.org/css-values-5/#if-notation
... and there are rules around cyclic evaluation in CSS:https://drafts.csswg.org/css-values-5/#cyclic-substitution-c...
Phew.cant wait to hang pages with ring oscillators
[dead]