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

> Did you see https://github.com/w3c/csswg-drafts/issues/6684#issuecomment-1069317315? Which went unanswered by the Sass maintainers, just like every other proposed solution here.

There's no call to be so combative about this. This thread is moving very quickly, and I have many responsibilities outside of this debate. I've also addressed many of these points repeatedly in other venues, but I'm happy to summarize them here:

### "Just add a flag"

Once you're adding an external flag to control a core behavior of a language you've already lost the battle for usability. Zero users will know intuitively when and how to use a flag, and even those who think to look for it will need to wade through documentation and have a thorough understanding of exactly how they've installed Sass and how to pipe a flag through whatever layers of infrastructure exist around it, if indeed they even have permissions to do so.

Worse even than that is the fact that the core feature of Sass isn't the language but the *ecosystem*, in which many different libraries and design systems coexist and interact. A global flag is a complete non-starter because it creates a situation in which libraries become mutually incompatible with one another and some require the user to set up their environment correctly to even use them. Package-by-package or file-by-file flags introduce massive additional complexity to the language to the extent that they provide no real benefit on top of a naive migration.

### "Delay the feature until Sass is migrated"

This is a lose-lose proposition. It mitigates almost no pain on the part of Sass users—they still have to endure the migration process, which I will emphasize again would be unspeakably painful and unpopular. In the meantime, CSS users will have to wait to have access to this feature. The Sass world is large, and migrations take a long time. For example, it's been a year and a half since the LibSass implementation was deprecated and three years since it had any new features land, and more than a third of Sass users still use it—and that's despite substantial incentives to use the new implementation in terms of CSS compatibility and new features.

### "You shouldn't have used `@if`"

As @tabatkins points out, this ship sailed in 2008 and we exist in a world where that decision was made. Even saying that, I think a lot of people probably don't remember what the CSS ecosystem was like in 2008. It was unthinkable at the time that one day CSS would want to add its own native `@if` rule—CSS specs evolved at a glacial pace, implementation was even slower, and the only new things that were being added were extremely specific to visual styles or browser detection. Why would it want a procedural-looking conditional? No one in any of the discussions around `@if` or any other Sass feature ever even *raised the possibility* that it might cause a conflict. It was only in the mid 2010s that CSS started accelerating to the degree that we began thinking seriously about how to avoid conflicts in the future.

### "Parse CSS `@if` and Sass `@if` separately"

This is the most plausible of the proposals I've seen above. It's effectively what we did when CSS added support for `min()` and `max()` which conflicted with Sass's built-in functions (which I'll mention again, we moved off of without complaint—we aren't inherently opposed to migrations, I'm raising a flag for this one because it will be uniquely massively disruptive). However, it has two major problems:

1. It means that Sass needs to constantly keep its syntax for plain-CSS `@if` up-to-date so that it knows how to disambiguate between the two syntaxes. Normally when CSS adds support for a new at-rule, Sass automatically supports it through its default at-rule parsing. If we had to explicitly parse plain-CSS `@if`, every new condition that was added would be *unsupported by default* in Sass until we implemented the new parsing and users upgraded to it. That's a much worse user experience.

2. More importantly, this solution relies on a strictly unambiguous parsing where Sass expression syntax (or at least expressions that are meaningful in a boolean context) have zero overlap with plain-CSS conditional expressions. This is already not the case in the draft proposal: `@if media(screen)` is valid, meaningful, potentially useful Sass that works today.

This does suggest one potential compromise: if CSS adjusted the syntax of `<boolean-condition>` to ensure it doesn't and never will conflict with a valid Sass boolean expression (a straw example would be surrounding it with square brackets), we could just suck up the usability pain of issue 1 above and parse both in parallel. My feeling though is that this would be much weirder from the perspective of a CSS user than simply using `@when`.

Which brings me to my last point:

> the Sass maintainers do not seem to even be interested in discussing a win-win solution to this.

The win-win solution is to use the name `@when`, which is why Tab proposed that in the first place. There have been plenty of explanations in this issue and elsewhere about why that name is appropriate. Setting linguistic bikeshedding aside, it seems like the primary practical reason *not* to use it is familiarity for users of other programming languages, but even that is on shaky ground in my opinion (and I'm doing my best to put on my non-Sass hat for this) because the languages other people are familiar with use `@if` in a procedural way that's not just inaccurate but potentially misleading for CSS.

Again, Lea, I don't understand why you're so set on being combative about this. I want to emphasize again that Sass has, in every other area that it's ended up conflicting with CSS, quietly ceded the space to CSS's syntax even when that's caused substantial pain to our users. I'm raising a red flag for this issue not out of principle or a misguided sense of territoriality, but because I genuinely believe it will be dramatically worse for Sass users than any previous syntactic conflict.

If your anger is because I made a tweet, please allow me to apologize. My intent was not to brigade—I specifically only asked for :+1:s because I wanted to demonstrate that this was a real issue affecting real users, but I hear you saying that it wasn't helpful and I won't do it again.

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


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

Received on Thursday, 17 March 2022 22:49:04 UTC