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

We can disagree on the best path forward for CSS, but the facts remain: Sass exists, it is very broadly used, Sass authors are CSS authors, the Sass team cares deeply about the future of CSS and our role in supporting that, and also Sass has a nearly 15yr ecosystem built around `@if` as one of the most-used core features.

It's frustrating how much of this conversation has resolved around questioning & attacking Sass, or trying to tell the Sass team how to 'easily' make that breaking change. Sass has been around for a very long time, and I promise we understand how to maintain an open source project. Yes, we already know we might have to take those steps, and we understand the options available – explaining to us how to make the update is not helpful. 

**Natalie was asked to explain the impact of this specific change on Sass users, and she did that.** It would be pretty devastating to a 15yr old ecosystem that doesn't update quickly or simply. Even tools like Codepen are still using a massively outdated version of Sass, because breaking changes _break things_. It's easy to wave that away in the abstract, or when dealing with a single Sass file – but the reality is projects have dependencies that have dependencies, etc.

That impact on the Sass ecosystem and Sass authors isn't changed by how much we wish it wasn't the case. We all agree that the ideal situation is one where we no longer run into these conflicts at all. And Sass has made significant efforts over the last decade to preemptively 'move out of the way' for new CSS – far beyond the few places mentioned, where actual conflicts have come up. It's disingenuous to suggest we should 'consider' doing that, when we've been actively doing it for some time now, and we will keep working on it. Sass is not somehow squatting on all the syntax we've ever used – but some updates are harder than others.

**The impact on Sass users would be major.** That's a fact, no matter how we go about making the change. This is not a thread about what Sass should have done, or what Sass should do now. Can we please focus on the question at hand? Now the CSSWG gets to determine how we balance that pain for CSS/Sass authors against other considerations. As we should. _Given the fact that we're in this situation, and having heard from the lead Sass designer about the potential harm to CSS/Sass authors, what does the CSSWG want to do next_? 

If the starting premise is that _the only acceptable resolution_ is for CSS to use `@if`, and all other proposals are invalid, then I'm not sure why we're even having a discussion? 

Meanwhile, the spec author (@tabatkins) has proposed `@when` as a good alternative – not 'only' to avoid conflicts with Sass (as was suggested), but also to clarify a fundamental difference between this CSS feature and the `if` construct that is commonly used in procedural languages. `@while` has [also been suggested by @AmeliaBR](https://twitter.com/AmeliasBrain/status/1504659144342753280?s=20&t=bQgm_4Mj-pexpzyJmnCZuA), and is a more viable deprecation for Sass to make. 

I understand that many people are _familiar_ with `if` as a term for conditionals, and that many people would _like_ for that same term to be used in CSS, but I'm not convinced that makes it clearly, fundamentally, and unquestionably _better_ as a choice. To my mind, the alternative proposals better express how CSS conditionals actually _are different from procedural `if`_: not a one-time control-flow, but dynamic conditions in a declarative system. While I understand it's not the first choice for some people, I'm not convinced there's a significant harm to CSS authors in using one of those terms.


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


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

Received on Friday, 18 March 2022 18:35:35 UTC