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

I'd like to respond to some of the things said by @nex3.

First, I'd like to comment on the comparison with `math.div` and `/`, because I don't think this is a fair comparison. The slash as a divider has existed since the birth of CSS, far before SASS was created. It was a design decision from SASS (presumably an early one) to treat slashes as division in some contexts and as a separator in others. Over time, it became clear this was a mistake, as CSS started to use slashes in more places, and `math.div` was the solution. That was rectifying a decision that was made in the past. `@if` does not currently exist in CSS, and its deprecation in SASS would be to make room for a new feature in CSS. For me as a developer, the latter is much more understandable than the former. Deprecating `@if` is pretty straight-forward; CSS is going to use it and SASS is adapting. On the other hand, the slash already existed in both SASS and CSS, and why that's being deprecated is, from my point of view, a lot more nuanced. What I'm getting at, is that developers being annoyed because of breaking changes in the tools they use does not necessarily mean they disagree with the decision. I, for one, would be annoyed too if SASS deprecated `@if` in favor of CSS `@if` - trying to work around issues with SASS `@if` and CSS `@if`, whether that's in stylesheets themselves, in config files, or in libraries I'm using, would frustrate me quite a bit. But, I'm still leaning towards `@if` because I think CSS will be better for it. Frustration does not mean disagreement.

Second, I would like to talk about the fact that SCSS is a superset of CSS. It was noted that this is a "purity argument", and while that is true, the fact that that is low on CSS's priority list does not mean it should be low on SASS's. The SASS team has its own values, and may attribute their own weights to each. If SCSS being a superset of CSS is considered important, then I understand and respect that - I don't think it is fair to dismiss that as a low-quality argument. I would personally prefer if SCSS kept this specific value up, and remained a superset of CSS, even if that means I have to go through migration efforts. I imagine some others might feel the same.

Lastly, I want to comment on the last paragraph of @nex3's response. Specifically, the phrases "Sass users are CSS users, and harming them harms CSS users" and "Don't alienate them over word choice" shows their protective stance over the SASS community (which is understandable, given @nex3's position) but it seems to overlook the fact that many of us, in this very conversation, _are_ SASS users, myself included. The way I see it, we're all part of the same community. We're all developers. We're having a discussion in order to decide whether to use `@if` or `@when`. Begging to choose `@when` on behalf of the SASS community, which many of us are part of, is, in my honest opinion, not an argument for `@when`.

Now, let's look at the situation concretely. There are two ways this can play out, depending on the stance the SASS team takes - either they acknowledge and embrace the fact that CSS is thinking of using `@if`, and we can start looking for solutions, together. Or, they can stay firmly against `@if`, forcing the CSSWG to make a tough decision; do they ignore SASS, emitting an attitude of "we don't care what you say", or, do they bend things the way SASS wants them to, going for the less optimal option? Both of these set a bad precedent, really; the first for obvious reasons, and the second would create the illusion that frameworks or preprocessors becoming popular enough means they can bend CSS to their will.

As such, I urge SASS to stay open-minded. Let's work together towards a solution we all want. If that's `@when`, that's okay - but let's stay objective. For one, rather than sending out tweets asking for thumbs up on a post in this thread, SASS could try to stay neutral and instead send out a tweet polling what SASS users _actually_ want, accompanied by a quick, unbiased overview of the problem. I'm sincerely hoping we can cooperate as one, and look back on this situation in 10-20 years, knowing we handled it well.



-- 
GitHub Notification of comment by vrugtehagel
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6684#issuecomment-1070985916 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 15:41:07 UTC