[css-conditional-4] Rename @when to @if #6684
Description
The reasoning for using @when over @if is that @if clashes with Sass, a widely used CSS preprocessor. To my knowledge, 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 w3ctag/design-principles#335 which has received a lot of attention from the Sass community through this tweet.
My take:
- 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
@whenkeyword 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. It's like Babel forcing TC39 to not change a proposal because too many people transpile it a certain way. - 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.
- There is precedent for using
iffor conditionals in almost every language that includes conditional statements (and not just imperative languages as has been erroneously mentioned). For example, spreadsheets and all flavors of SQL (SQL Server, MySQL, even SQLite), Lisp, Haskell, Erlang, XSLT, all of which are considered declarative. - Many ways for Sass to deal with this change have been mentioned in [mediaqueries][css-conditional] else #112. There could be a switch, users can use an old version of Sass until they are ready to migrate, and so on. Ways for Sass to avoid clashing with CSS have been mentioned too. 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,@whileare all taken. How much do we contort CSS to avoid clashing with preprocessors? - 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,
@whenhas 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
ifis more synchronous. - There are thoughts to add inline conditionals as well (e.g. [css-values]: Express conditional values in a more terse way #5009 ). Are we going to name those functions
when()as well? Are we going to name them something unrelated, likecond()? Do note that these also clash with Sass if calledif()... link
- Note that the even the CSS WG resolution to adopt this proposal said "if/else". This is how entrenched this naming is! If
@whenis adopted, this will make for decades of users mistyping CSS conditionals.
Quotes from [mediaqueries][css-conditional] else #112:
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.
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
@ifor just transparently convert something like@css-ifor@native-ifto 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.
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
@whenand@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
@ifthan 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?
I strongly prefer @if, @else, and @else-if. It would be clear and obvious for most authors, and SASS could easily adapt.
I'd like to express my strong agreement with @upsuper, @Marat-Tanalin and @bradkemper above in favor of
@ifover@when.
- Consistency with every other language authors may have used
- 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.
- 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:
@ifis used quite heavily: about 63% of Sass stylesheets use it. But even if it was used in 100% of them we should not design CSS around Sass.
Adding my agreement to call this
@ifnot@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.