Re: [csswg-drafts] [css-conditional-4] Rename @when to @if (#6684)

@pygy

> @ai @matthew-dean @iChenLei What do you think of this ?

Interesting. So, I am one of the maintainers of Less, which still has a large user base. Although I get that Sass and it's substantial resources have probably pushed it in popularity past Less at this point, but I would say Less and its language design are probably relevant to this discussion.

Less doesn't have conditional `@if` blocks, not because they're not arguably useful, but because they don't really mimic CSS's declarative nature. Sass "runs" as an imperative language, from top to bottom, with embedded CSS pieces, like PHP w/ HTML. Less's language design tried to mimic CSS's declarative patterns. That's why, for example, Less variable declarations have a value per selector block, and can be referenced "before" they are declared, like CSS.

Anyway, germane to this discussion, Less has `when` guards on selectors and mixins, not "if / else" patterns which mimic languages that run from top to bottom.

I didn't know CSS was considering this at all, because CSS is not an imperative programming language, so `@if` and `@else` are completely strange concepts in terms of "what's evaluated when" when you have selector / element-level values. (A `@supports` query, for example, has no "awareness" of other `@supports` queries, yet this would introduce the concept that an `@else` block is an at-rule whose evaluation depends on another at-rule) An `if()` function, in contrast, has a much lower cognitive overhead, and is closer to the logic of other "value-picking" functions like `min` / `max` etc, and Less has an `if()` function for this reason.

Btw, I'm not saying a CSS author could _not_ understand if/else logic, but I do think people who are used to Sass have a little bit of--what would it be called--selection bias? 🤔  As in, assuming that it's not complicated because you're used to seeing it in Sass. In general, people familiar to Sass underestimate the cognitive complexity of the language and some of its concepts (such as mixing imperative and declarative ideas). That's not to bash Sass; it's fine, and I've used it in a number of workplaces. That's just to say: the fact that CSS authors are considering either `@when` or `@if` is really kind of bewildering, when there are other patterns to express the same thing that introduce less cognitive complexity.

THAT SAID, that's a little off-track from this topic / question, so what do I think, about using `@when` vs `@if`? (And putting aside that I think this should really be re-considered.)

1. I mean... I raised similar concerns about nesting syntax, as it behaves different from Less / Sass, and it would be non-trivial to signal when you want the pre-processor to process something vs when you want it to "pass through". So I'm sympathetic to the argument that you'd be making life harder for users using pre-processors. That said, the creator of Less, Alexis Sellier, stated his opinion that hopefully, one day, CSS would get to a place where pre-processors aren't needed. If CSS added nesting, when guards (conditionals), mixins, and global variables (or allowed sharing state / vars with JS!), Sass and Less could essentially cease to exist. So, following his lead, my hope would be that CSS would do what's best for CSS, so I'm sympathetic to @LeaVerou's argument.
2. Buuuuut, again, I would say the reason to use `@when` (if this concept moved forward) is because it's actually a better keyword for CSS, and doesn't have the baggage of importing an imperative model that doesn't apply and that `if` / `else` sort of brings with it. Unless CSS spec authors are _wanting_ to import an imperative model to CSS stylesheets, which... is that part of the goal? To change the way we think about stylesheets / CSS declarations? 🤔  I mean, is it really the goal to make CSS more like Sass and thus appropriate an entirely different mental model? (To have CSS resemble more of a programming language?) I really don't get that as a goal. If you want more programming-language like constructs, I personally would follow other paths like finding ways to re-define the language to share state / variables with JavaScript. (There was a recent great Twitter thread by a CSS thought leader on this topic -- I couldn't find it off-hand 🤔 ) Or expand the capabilities of worklets so that custom at-rules could be defined to create any logic the CSS author would provide.

Anyway, I probably won't change any hearts and minds of people who are very used to Sass and thus feel that `@if` or `@when` is really necessary. But, if this goes ahead, I think there are more arguments for `@when` than just "`@if` would conflict with Sass."

Good luck!

-- 
GitHub Notification of comment by matthew-dean
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6684#issuecomment-1073147604 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 20 March 2022 01:55:55 UTC