6 ms·

I've been writing CSS for well over a decade, and as much as I love it, there's one thing I've always been irked about. The language lacks an explicit if/else s

I've been writing CSS for well over a decade, and as much as I love it, there's one thing I've always been irked about. The language lacks an explicit if/else syntax because the authors felt that the presentation layer shouldn't be responsible for "behavior", which is how they think of logic. So what's funny here is that this article perfectly illustrates why the lack of an else/if is just pure silliness. There's "behavior" embedded everywhere in CSS, it's just all so implicit that it almost goes unnoticed.

madeofpalk 4y ago
What's an example of something you could do with an if/else, that's not possible today? I think this article demonstrates why an if-statement is not needed when you can declare rules of how styles are applied.
- danielvaughn 4y ago
  It’s not about functionality, it’s about being explicit and clear. Had the authors decided to include an if/else construct, it would have meant that none of those other concepts were even necessary. You could have bundled all of them together under one syntax. Much cleaner and easier to understand.
  - psygn89 4y ago
    I think part of the problem was that selectors that looked inwards or outwards from an element was deemed too expensive to parse. It only looked at the current element or following adjacent ones (with + or ~). Now that it's deemed doable without noticeably hurting performance, :has/:not(:has()) basically comes around and allows you the inward/outward selector lookups, e.g. (`.container:has(input:checked) { border: 1px solid green }` ). That said, I do agree it would've been nice if they had the foresight to use `:has(:checked)` (or some kind of :if() syntax), but it's all hindsight 20/20 and it was the wild west on the web back when a lot of these features were spec'd/implemented. Kinda wish there was a new css version every 10 years or so to fix the inconsistencies (which you would have to opt into).
  - madeofpalk 4y ago
    What's an example that's not explicit or clear enough? I think `p:empty { }` is a perfectly clear syntax. As the article says it's already a conditional statement - just imagine an invisible `if` in front of every selector or media query. CSS is not a procedural language, so I think that if statements could be less clear about how rules are applied.
    - brigandish 4y ago
      > just imagine an invisible `if` in front of every selector or media query. That reminds me of how I'm supposed to imagine an invisible watashi or an invisible ga in Japanese sentences, which is also incredibly difficult for for non-native speakers to do well (at least, in the beginning, which most do not get far beyond) and causes all sorts of problems for translation engines. So how about making the language explicit, clear, and hence easier for humans to reason about? All this all you have to do stuff reminds me of how adherents speak about C and Git. Thank God we're seeing viable replacements for C, and I have hope in a replacement for Git (jj or pijul? I pray). If something comes along that is less painful than CSS I'll be the first to jump and I won't be alone.
- bryanrasmussen 4y ago
  I think the way most people would want an if else to work in CSS is that you can say if this path exists then apply a list of rules that might not have anything to do with that path else some other list. Let's suppose we have a match function that could be used like this :root { --has-path: match(.modal .message .error); } and then if the following were allowed (or some variation were developed where this could be done) .user:has(var(--has-path)) {color: red} I think it might be nice. YMMV however. on edit: thinking about it however while it might be nice if you could do queries like that, it does seem like it would be expensive (for browser performance) to implement.
  - madeofpalk 4y ago
    The only missing part from your example is supporting custom properties in selectors, which can't really work because custom properties are scoped and cascade, like regular properties. I'm not sure I totally understand the specifics of the example, but it's probably possible to get something close with the nested selectors spec being worked on now, and/or :is()
    - bryanrasmussen 4y ago
      >The only missing part from your example is supporting custom properties in selectors I figured it was implied some rules would have to be made which might be properties used in selectors are scoped to ancestors of element. >I'm not sure I totally understand the specifics of the example example is probably too fanciful but assuming you have a match of selector .modal .message .error then element with class user which is on a totally different part of the page - like body header ....stuff .user /header article section .modal .warning .error then user has color red. Do I personally want this, not much, just considering the people who sometimes say they want if ( selector exists) then bunch of css. another more likely usage for something like this (a match function that takes a selector) might be the various CSS logical operations things people do sometimes https://css-tricks.com/logical-operations-with-css-variables/ https://css-tricks.com/logical-operations-with-css-variables... however, as I noted before I don't think it makes sense for css performance reasons, despite how interesting/amusing I might find the idea.
- downvotetruth 4y ago
  Cannot read inputted text from textarea/input/contenteditable div element into a var that is then conditioned - limited to explicit input (in)validation match.
glasss 4y ago
I think you and the blog post make sense. If you present people with a outside-in view of building a website, I wager they would agree that form and presentation layers have a huge impact of behavior, expected or implicit. With the inside-out view of HTML then CSS, it feels like that same stance gets muddied because of the technical aspects of the languages and their original intents.
sebazzz 4y ago
CSS is reaching the point for me that it is becoming too complex. I'm perfectly fine with complex backends though - CSS though, there are now so many options and so many ways to do things. It must probably be me though.
- suprjami 4y ago
  It isn't just you. I work on systems software - kernel, daemons, networking, debuggers, machine language disassembly - so I'm used to looking at things which other people say are "hard". Nothing frustrates me more than writing a Stylus rule or figuring out how to place an element on my Jekyll theme. Every time I do this, my appreciation for modern well-made websites doubles. CSS is so opaque and impossible, I wouldn't be a web developer for any money.
  - zamadatix 4y ago
    The hard part about working with CSS is that, beyond syntax, nothing is an error. No matter how far it is from doing what you intended to do it's always going to give you a layout with no hint how it's actually different from what you wanted beyond "that doesn't look right".
    - epicureanideal 4y ago
      But is that very different from code with logic bugs despite correct syntax? The solution for code is unit tests. Maybe the css needs that also.
      - zamadatix 4y ago
        In code it's very easy to add your own errors/asserts which say "you dummy, you can't possibly fit these 3 things here the way you want" and then go modify your code so you can handle it the way you wanted. It's worth testing because when a test breaks you can modify it so the test passes. In CSS you can't customize that latter half though, if the 3 things render wonky when they don't fit you just have to hope there is some way to tell CSS to render it the way you want. Sure, you can run a test that says it failed to create the layout you were hoping for... but you already knew that and test or no test your only hope is you can find some way to do it with the predefined options in CSS. And the fun part is sometimes there is no way! You may just have to compromise on how your layout works or push some logic to JS to change the styling so you can do something more akin to the normal code way (at the loss of performance and clarity).
gnull 4y ago
The current syntax also makes it hard to characterize the class of predicates that can be expressed with CSS. Kind of hurts my sense of perfectionism, but I guess it wasn't their goal. I assume CSS was made very restrictive on purpose so that it can be applied to the page elements and analyzed very efficiently.
isleyaardvark 4y ago
Years ago I came to the conclusion that CSS should be treated as just a place to dump reusable styles, and all logic should be in the html/templating language. It's made my life significantly easier.
- alwillis 4y ago
  > Years ago I came to the conclusion that CSS should be treated as just a place to dump reusable styles, and all logic should be in the html/templating language. Coding like this removes so much of the flexibility and power of CSS. The reason we have media queries and now container queries and style queries is because HTML is for structure and CSS is for presentation and the state of things being presented. If a user selects high contrast mode because they're sight impaired, that's a state issue that has to be handled by CSS; HTML can't help you here: @media screen and (forced-colors: active) { … … } To anyone who's learned CSS properly sees this as "IF the user wants forced-colors mode (previously high-contrast mode), THEN execute the selectors between the braces." This is certainly cleaner than an explicit IF/THEN construct for this particular feature.
  - valenterry 4y ago
    I recently tried that and it simply doesn't work because even in the latest version CSS is unusable for anything remotely complex or without repeating code. Gave up and am doing it like OP now. CSS MUST become a proper programming language (or at least non-turing-complete configuration language like dhall) to solve this.
  - nonethewiser 4y ago
    > HTML is for structure and CSS is for presentation These really arent decoupled.
greggman3 4y ago
I believe the reason there's no if/else is because CSS is supposed to be easy enough to interpret relatively quickly (in a finite amount of time). The moment you add if/else you'd up with a full programming language and the halting problem and an arbitrary amount of calculations before the system can finally know what to render.
- erezsh 4y ago
  I think that would require while/recursion? Afaik ifs are very quick to calculate.
- valenterry 4y ago
  So what's the issue here? Why is this not a problem for Javascript but for CSS? In the worst case just put a 3sec limit on the evaluation and stop it if it doesn't complete in time, problem solved.
  - cal85 4y ago
    You solved the halting problem!

madeofpalk 4y ago

What's an example of something you could do with an if/else, that's not possible today? I think this article demonstrates why an if-statement is not needed when you can declare rules of how styles are applied.

danielvaughn 4y ago
It’s not about functionality, it’s about being explicit and clear. Had the authors decided to include an if/else construct, it would have meant that none of those other concepts were even necessary. You could have bundled all of them together under one syntax. Much cleaner and easier to understand.
- psygn89 4y ago
  I think part of the problem was that selectors that looked inwards or outwards from an element was deemed too expensive to parse. It only looked at the current element or following adjacent ones (with + or ~). Now that it's deemed doable without noticeably hurting performance, :has/:not(:has()) basically comes around and allows you the inward/outward selector lookups, e.g. (`.container:has(input:checked) { border: 1px solid green }` ). That said, I do agree it would've been nice if they had the foresight to use `:has(:checked)` (or some kind of :if() syntax), but it's all hindsight 20/20 and it was the wild west on the web back when a lot of these features were spec'd/implemented. Kinda wish there was a new css version every 10 years or so to fix the inconsistencies (which you would have to opt into).
- madeofpalk 4y ago
  What's an example that's not explicit or clear enough? I think `p:empty { }` is a perfectly clear syntax. As the article says it's already a conditional statement - just imagine an invisible `if` in front of every selector or media query. CSS is not a procedural language, so I think that if statements could be less clear about how rules are applied.
  - brigandish 4y ago
    > just imagine an invisible `if` in front of every selector or media query. That reminds me of how I'm supposed to imagine an invisible watashi or an invisible ga in Japanese sentences, which is also incredibly difficult for for non-native speakers to do well (at least, in the beginning, which most do not get far beyond) and causes all sorts of problems for translation engines. So how about making the language explicit, clear, and hence easier for humans to reason about? All this all you have to do stuff reminds me of how adherents speak about C and Git. Thank God we're seeing viable replacements for C, and I have hope in a replacement for Git (jj or pijul? I pray). If something comes along that is less painful than CSS I'll be the first to jump and I won't be alone.
bryanrasmussen 4y ago
I think the way most people would want an if else to work in CSS is that you can say if this path exists then apply a list of rules that might not have anything to do with that path else some other list. Let's suppose we have a match function that could be used like this :root { --has-path: match(.modal .message .error); } and then if the following were allowed (or some variation were developed where this could be done) .user:has(var(--has-path)) {color: red} I think it might be nice. YMMV however. on edit: thinking about it however while it might be nice if you could do queries like that, it does seem like it would be expensive (for browser performance) to implement.
- madeofpalk 4y ago
  The only missing part from your example is supporting custom properties in selectors, which can't really work because custom properties are scoped and cascade, like regular properties. I'm not sure I totally understand the specifics of the example, but it's probably possible to get something close with the nested selectors spec being worked on now, and/or :is()
  - bryanrasmussen 4y ago
    >The only missing part from your example is supporting custom properties in selectors I figured it was implied some rules would have to be made which might be properties used in selectors are scoped to ancestors of element. >I'm not sure I totally understand the specifics of the example example is probably too fanciful but assuming you have a match of selector .modal .message .error then element with class user which is on a totally different part of the page - like body header ....stuff .user /header article section .modal .warning .error then user has color red. Do I personally want this, not much, just considering the people who sometimes say they want if ( selector exists) then bunch of css. another more likely usage for something like this (a match function that takes a selector) might be the various CSS logical operations things people do sometimes https://css-tricks.com/logical-operations-with-css-variables/ https://css-tricks.com/logical-operations-with-css-variables... however, as I noted before I don't think it makes sense for css performance reasons, despite how interesting/amusing I might find the idea.
downvotetruth 4y ago
Cannot read inputted text from textarea/input/contenteditable div element into a var that is then conditioned - limited to explicit input (in)validation match.

glasss 4y ago

I think you and the blog post make sense. If you present people with a outside-in view of building a website, I wager they would agree that form and presentation layers have a huge impact of behavior, expected or implicit. With the inside-out view of HTML then CSS, it feels like that same stance gets muddied because of the technical aspects of the languages and their original intents.

sebazzz 4y ago

CSS is reaching the point for me that it is becoming too complex. I'm perfectly fine with complex backends though - CSS though, there are now so many options and so many ways to do things. It must probably be me though.

suprjami 4y ago
It isn't just you. I work on systems software - kernel, daemons, networking, debuggers, machine language disassembly - so I'm used to looking at things which other people say are "hard". Nothing frustrates me more than writing a Stylus rule or figuring out how to place an element on my Jekyll theme. Every time I do this, my appreciation for modern well-made websites doubles. CSS is so opaque and impossible, I wouldn't be a web developer for any money.
- zamadatix 4y ago
  The hard part about working with CSS is that, beyond syntax, nothing is an error. No matter how far it is from doing what you intended to do it's always going to give you a layout with no hint how it's actually different from what you wanted beyond "that doesn't look right".
  - epicureanideal 4y ago
    But is that very different from code with logic bugs despite correct syntax? The solution for code is unit tests. Maybe the css needs that also.
    - zamadatix 4y ago
      In code it's very easy to add your own errors/asserts which say "you dummy, you can't possibly fit these 3 things here the way you want" and then go modify your code so you can handle it the way you wanted. It's worth testing because when a test breaks you can modify it so the test passes. In CSS you can't customize that latter half though, if the 3 things render wonky when they don't fit you just have to hope there is some way to tell CSS to render it the way you want. Sure, you can run a test that says it failed to create the layout you were hoping for... but you already knew that and test or no test your only hope is you can find some way to do it with the predefined options in CSS. And the fun part is sometimes there is no way! You may just have to compromise on how your layout works or push some logic to JS to change the styling so you can do something more akin to the normal code way (at the loss of performance and clarity).

gnull 4y ago

The current syntax also makes it hard to characterize the class of predicates that can be expressed with CSS. Kind of hurts my sense of perfectionism, but I guess it wasn't their goal. I assume CSS was made very restrictive on purpose so that it can be applied to the page elements and analyzed very efficiently.

isleyaardvark 4y ago

Years ago I came to the conclusion that CSS should be treated as just a place to dump reusable styles, and all logic should be in the html/templating language. It's made my life significantly easier.

alwillis 4y ago
> Years ago I came to the conclusion that CSS should be treated as just a place to dump reusable styles, and all logic should be in the html/templating language. Coding like this removes so much of the flexibility and power of CSS. The reason we have media queries and now container queries and style queries is because HTML is for structure and CSS is for presentation and the state of things being presented. If a user selects high contrast mode because they're sight impaired, that's a state issue that has to be handled by CSS; HTML can't help you here: @media screen and (forced-colors: active) { … … } To anyone who's learned CSS properly sees this as "IF the user wants forced-colors mode (previously high-contrast mode), THEN execute the selectors between the braces." This is certainly cleaner than an explicit IF/THEN construct for this particular feature.
- valenterry 4y ago
  I recently tried that and it simply doesn't work because even in the latest version CSS is unusable for anything remotely complex or without repeating code. Gave up and am doing it like OP now. CSS MUST become a proper programming language (or at least non-turing-complete configuration language like dhall) to solve this.
- nonethewiser 4y ago
  > HTML is for structure and CSS is for presentation These really arent decoupled.

greggman3 4y ago

I believe the reason there's no if/else is because CSS is supposed to be easy enough to interpret relatively quickly (in a finite amount of time). The moment you add if/else you'd up with a full programming language and the halting problem and an arbitrary amount of calculations before the system can finally know what to render.

erezsh 4y ago
I think that would require while/recursion? Afaik ifs are very quick to calculate.
valenterry 4y ago
So what's the issue here? Why is this not a problem for Javascript but for CSS? In the worst case just put a 3sec limit on the evaluation and stop it if it doesn't complete in time, problem solved.
- cal85 4y ago
  You solved the halting problem!