- From: Iain E. Davis via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Sep 2021 20:14:33 +0000
- To: public-css-archive@w3.org
My observation is that `@when` is a better choice than `@if`. Given the nature of CSS and its purpose, @when is language that is closer to CSS' role. That is, "when this condition exists apply this style" communicates intent far more clearly than "if this condition apply this style" I think it is important to recognize that CSS is a not a general purpose language. It is a domain-specific language. An essentially part of a domain specific language is keeping the domain of the language in mind when making keyword and syntax decisions. I'd also argue that when a language uses a different-from-the-familiar keyword, that can signal to a engineer that the keyword may not operate with the same sense or nuance that it does in another language. This could be particularly valuable in a language like CSS, where its nature is very different from general purpose languages. > The reasoning for using @when over @if is that @if clashes with Sass, a widely used CSS preprocessor. No other reasoning exists for this decision. That may be the reasoning of the folks that selected `@when`, but that certainly wouldn't be _my_ reasoning. So there are definitely is other reasoning for making the decision. I've no special attachment to SASS, I regard it just as ephemeral is any other technology or tool. There's definitely some impacts to weigh there, SASS is widely used, and identifying a responsible migration path would be essential for this change. But that's not the only reason > We don't want to be stuck with a weird @when keyword decades after Sass is not used any more, making for yet another funny story about "why CSS is weird". I'd say most languages have such artifacts -- where the needs of the community of the time required the language to have a given feature. It's the reality of working on something _while it is in use_. Compromises have to be made to maintain compatibility with the users of a tool/language/technology. And I'd say it's misleading to call using @when as a reason to call CSS weird. Again, CSS is not a general purpose language. It has needs that general purpose languages do not, so naturally it will differ from general purpose languages. That's the whole point of creating a domain specific language. > There are far more CSS users than users of any particular preprocessor, so their needs should be weighed significantly more heavily. Not infinitely, but very significantly. This is a valid claim, _as far as it goes_. However, it focuses on the "quantity of those affected" without accounting for the "degree of impact". The impact of using `@when` over `@if` is relatively minimal, since the people affected by are highly intelligent and capable people. They can handle knowing that the conditional CSS syntax differs from other languages. However, for the community of SASS users, the impact _may be significant_. That'd depend entirely on what kind of backwards compatibility could be built by SASS. > There is precedent for using if for conditionals in almost every language Just because it was done before doesn't make it the best thing in every scenario or language. It may not have even been the best thing at the time, just happened to be what someone thought of. Hopper's comment on this fallacy is probably the best: "The most dangerous phrase in the language is, ‘We’ve always done it this way.’" I'm also curious what the actual statistics are around the 'if' keyword, and the connections between those languages that use it. I suspect we'll find a common set of ancestors (or ancestor) there. :) > What happens if in the future we want to add... That's the future's problem. One can "what if" any idea into oblivion or stagnation. > In natural language, "when" is used for something that hasn't happened yet, whereas if is more synchronous. Is CSS synchronous? I'd say it is more existential. It either is applied or is not. There's not, in some senses, a sequence to CSS. In natural language, _when_ does have "when this becomes true, ...". That also applies to _if_ -- "if this becomes true, ...". That it is not its only nuance. If we were talking tenses, it can also apply to "present perfect" in addition to the "future" tense you're referring to. For instance, the sentence "when I read, I wear funny hats" both captures _past_, _present_, and _future_ conditions. And only future because we're assuming my past and present behavior is predictive of future behavior. That nuance of _when_ applies to CSS quite well. "When my page is 900px wide, all text will be green" is a similar nuance as "when I read, I wear funny hats". > If @when is adopted, this will make for decades of users mistyping CSS conditionals. We still type???? ;) My guess it'll be typed once or twice, predictive text generated hundreds of times, and cut-and-pasted thousands of times. Again, CSS is its own domain. I think the context shift is sufficient to flip the switch in the brain from @if to @when. The arguments for and against don't feel compelling to me in either direction. The concerns about backward compatibility are valid but there are also times when one has to let an API change to accommodate future changes. Following common patterns has value but there are times when we have to adopt a new pattern -- otherwise we're stuck doing the same thing over and over, forever. Natural language and conveying intent is complicated to evaluate -- natural languages are richly varied and highly complex, while a programming language is, by design, specific (to their domain of machine instructions) and unambiguous. And domain languages are, by design, even more specific to their domain, Making _nuanced_ decisions about keywords of a language on that basis is difficult and fraught with cultural bias. :) -- GitHub Notification of comment by iain-davis Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6684#issuecomment-926894201 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 24 September 2021 20:14:36 UTC