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

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-conditional-4] Rename @when to @if ==
The reasoning for using `@when` over `@if` is [that `@if` clashes with Sass](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-221669910), a widely used CSS preprocessor. No other reasoning exists for this decision.

However, there is a lot of pushback against this decision (and general philosophy) in #112. I have gathered quotes about this below.

Some arguments against `@if` have been posted by Sass maintainers in https://github.com/w3ctag/design-principles/issues/335 which has received a lot of attention from the Sass community through [this tweet](https://twitter.com/SassCSS/status/1438966633226125314).

My take: 

1. Third party tools can change far more easily than web standards, which are supposed to last for decades. 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". The whole point of preprocessors should be to prototype features for CSS' future. Designing CSS around Sass is going the wrong way up the proper chain of dependency.
2. 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. 
3. There is precedent for using `if` for conditionals in most languages that include conditional statements (and not just imperative languages as [has been erroneously mentioned](https://github.com/w3ctag/design-principles/issues/335#issuecomment-924428863)). For example, [spreadsheets](https://support.google.com/docs/answer/3093364?hl=en-GB) and all flavors of SQL ([SQL Server](https://www.sqlservertutorial.net/sql-server-stored-procedures/sql-server-if-else/), [MySQL](https://dev.mysql.com/doc/refman/8.0/en/if.html), even [SQLite](https://www.sqlitetutorial.net/sqlite-functions/sqlite-iif/)), [Lisp](https://www.tutorialspoint.com/lisp/lisp_if_construct.htm), [Haskell](https://wiki.haskell.org/If-then-else), [Erlang](https://www.tutorialspoint.com/erlang/erlang_if_statement.htm), all of which are considered declarative.
4. Many ways for Sass to deal with this change have been mentioned in #112. There could be a switch, users can use an old version of Sass until they are ready to migrate, and so on. Many ways for Sass to avoid clashing with CSS have been mentioned in https://github.com/w3ctag/design-principles/issues/335 . CSS has had an extension mechanism for over a decade, it's called vendor prefixes. What happens if in the future we want to add a looping construct to CSS as well? `@each`, `@for`, `@while` are all taken. How much do we contort CSS to avoid clashing with preprocessors?
5. CSS has already made syntactic decisions to avoid clashing with Sass, namely square brackets over parentheses in grid properties. However, those were two alternatives that more or less had the same usability, so a decision to avoid clashing with Sass was more justifiable. Here, `@when` has serious usability problems:
 -  It goes against conditional naming in almost every structured language. 
 -  In natural language, "when" is used for something that hasn't happened yet, whereas `if` is more synchronous. 
 - There are thoughts to add inline conditionals as well (e.g. #5009 ). Are we going to name those functions `when()` as well? Are we going to name them something unrelated, like `cond()`? Do note that these also clash with Sass if called `if()`... [link](https://www.tutorialspoint.com/sass/if_function.htm)
6. Note that the even the [CSS WG resolution to adopt this proposal](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-920196812) said "if/else". This is how entrenched this naming is! If `@when` is adopted, this will make for decades of users mistyping CSS conditionals.
Quotes from #112: 

[@Marat-Tanalin (1)](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-221681433):

> Fwiw, in the past, a SASS developer said at www-style that existing features of SASS should **not** be considered as limitations for new CSS features in any way:
> 
> if a potential new CSS feature is conflicting with an existing SASS feature, then the **latter** could just be changed.

[@Marat-Tanalin (2)](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-221726933):

> > Yeah, Sass usage does not trump CSS. But there's also no reason to be hostile to the developer community when we can easily avoid such.
> 
> Replacing the clear straightforward keyword widely used in almost all languages with an invented more-or-less similar one is actually probably not that _easy_.
> 
> At the same time, SASS (as well as any other preprocessor) could really easily rename its `@if` or just transparently convert something like `@css-if` or `@native-if` to native CSS `@if`. That’s not a CSS problem at all.
> 
> CSSWG decisions should probably not be based on the goal of avoiding preprocessor conflicts. CSS is a much more fundamental thing that require carefully weighed decisions reasonable and usable in the long term. Preprocessors can be changed at any time, **CSS cannot at all**.

[@upsuper](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-221835505):

> I'd prefer `@if`... not very strongly, though.
> 
> I agree with @Marat-Tanalin that we should not pick a weird syntax just to avoid conflicting with a preprocessor, and preprocessors can always work around that easily, either via a breaking change stated in the release note or introducing a new keyword.
> 
> I can imagine that if we choose `@when` and `@else-when`, more developers would tend to critize that CSSWG is making their life harder via adding some syntax different than what they are familiar with, rather than appreciating the work of avoiding the imaginary breakage.
> 
> I think the criteria is, is there more web developers use SASS's `@if` than those who do not use SASS's `@if` (or do not use SASS at all) but familiar with the general if-else structure? What's the percentage?

[@bradkemper](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-302982454):

> I strongly prefer @if, @else, and @else-if. It would be clear and obvious for most authors, and SASS could easily adapt.

[@leaverou](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-919879061):

> I'd like to express my **strong** agreement with @upsuper, @Marat-Tanalin and @bradkemper above in favor of `@if` over `@when`.
> 
> 1. [Consistency](https://w3ctag.github.io/design-principles/#consistency) with every other language authors may have used
> 2. As has been repeatedly mentioned, we should not be designing CSS, a language that needs to last decades and for which the burden of changes is incredibly high, based on conflicts with a preprocessor that _happens_ to be in use today (and is already giving way to others, e.g. PostCSS). Preprocessors can adapt far more easily than CSS, and any third-party project ultimately has far fewer users than CSS. Many solutions for Sass have been suggested in this very thread.
> 3. Preprocessors are not executed on every page load, so it's far easier for Sass authors to migrate to a new syntax at their own time. This is not like the issue TC39 faced with `array.contains()` at all.
> 
> Note: `@if` _is_ used quite heavily: [about 63% of Sass stylesheets use it](https://almanac.httparchive.org/en/2020/css#fig-72). But even if it was used in 100% of them we should not design CSS around Sass.

[@svgeesus](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-919946127):

> Adding my agreement to call this `@if` not `@when`.
> 
> I recall that the Sass maintainers have explicitly stated that CSS should **not** avoid a good syntax just because Sass uses it; they are very willing to change so that CSS can get better.



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6684 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 15:26:42 UTC