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

I'm leaning towards `@if`. I'll explain why.

First of all, I want to talk about the difference in meaning between the words "if" and "when". I'm not a native English speaker, so I may get nuances wrong, but I think people generally agree that "when" implies some timescale, a moment in the future when a certain condition will inevitably happen. I can say "I don't know when I'll leave the house" and "I don't know if I'd leave the house" and they'd mean different things; the first implies I will leave the house, I'm just unsure at what point in time. The second implies I'm not sure whether I'll leave the house altogether, regardless of time. For this CSS condition, I don't believe it would make sense to use `@when`; the condition is not guaranteed to ever happen, and is not bound to time in any way. `@if` seems a much better choice in that aspect.

As for the clash with SASS, that's the bigger issue. I think most people _want_ to call this rule `@if`, otherwise we wouldn't be having this discussion. So ultimately, the question is "should we care about breaking this third-party tool when speccing CSS". The way I see it, it's a bit up to interpretation of what the "environment" really encompasses (specifically, if SASS is considered part of the ecosystem or not). As a person who doesn't particularly value SASS, I could easily say "SASS should suffer the consequences" but it's not quite that simple. Let me go into this a little deeper.

First, I want to address arguments along the lines of "we're bending some JavaScript features in order to not break the web, why can't we do the same for CSS". Yes, we did have to rename some things for JavaScript just because the initially proposed name would break things. In my opinion, this is a bit different. Let's say (hypothetically) I built a site 5 years ago using MooTools (specifically using `Array.prototype.flatten`) as well as SASS (specifically using `@if`). I've long forgotten about this site, but it's still up and running and let's assume that people use it often enough to care about it breaking. If JavaScript introduced `Array.prototype.flatten`, my site would break without my knowledge, even though I didn't touch it. This negatively affects users. If CSS introduced `@if`, then... well, nothing. I already built my CSS 5 years ago, and my CSS (the output) didn't use `@if`, so that's all good. My SCSS build may fail, but that's irrelevant; my site didn't break for its users. Basically, the difference between breaking something for a JavaScript library versus breaking a CSS preprocessor is that the latter doesn't directly impact users of the web, while the first may break many unmaintained sites when released in browsers.

Now, let's say I wrote a preprocessor that would clash with a new CSS feature, just like SCSS. Would I expect CSS to go out of its way to avoid doing so? No, definitely not, as the amount of users affected by my preprocessor breaking would likely be insignificant. Obviously, the difference with SCSS is that it has an absolutely massive user base. Many people would be negatively impacted by a change that would cause their SCSS to break, cause them to have to migrate or stick to an older SCSS version that prevents them from getting other juicy updates to SCSS. The question is whether or not we should take this into consideration. Is SCSS "part of the web ecosystem", and we therefore have to protect them from this type of inconvenience, or is SCSS just a third party tool that shouldn't be taken into consideration whatsoever when making decisions about CSS? This is (the way I see it, anyway) at the heart of this discussion, and it's a difficult question.

I wholeheartedly believe in making the web an amazing place for everyone, and breaking SCSS `@if` would, to say it bluntly, suck, for a lot of developers. On the other hand, I'm a bit of a purist, so I'd prefer not to make compromises on language features based on a tool that developers use. Additionally, SCSS is, in a way, more "temporary" and easier to change than CSS itself, so there could be a time where SCSS slowly dies out (perhaps because CSS itself became feature-rich enough for most developers) and by that time we're stuck with a less intuitive `@when` rather than just `@if`.

In the end, if we _can_ get away with introducing `@if`, I'd say we should. We had to make compromises for JavaScript because we had no choice, but here, we _do_ have a choice. If we'd introduce `@if` in browsers now, no site would be affected (not many, anyway, though this is just an assumption), but instead it'll cause a a major inconvenience to a lot of SCSS developers that they'll have to get through in order to create a "better future" for the next generation of developers, so to say.



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


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

Received on Tuesday, 28 September 2021 15:17:37 UTC