5 ms·

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 tho

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.

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.