5 ms·

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

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.

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.