When or If
Published 2 years, 9 months pastThe CSSWG (CSS Working Group) is currently debating what to name a conditional structure, and it’s kind of fascinating. There are a lot of strong opinions, and I’m not sure how many of them are weakly held.
Boiled down to the bare bones, the idea is to take the conditional structures CSS already has, like @supports and @media, and allow more generic conditionals that combine and enhance what those structures make possible. To pick a basic example, this:
@supports (display: grid) {
@media (min-width: 33em) {
…
}
}…would become something like this:
@conditional supports(display: grid) and media(min-width: 33em) {
…
}This would also be extended to allow for alternates, something like:
@conditional supports(display: grid) and media(min-width: 33em) {
…
} @otherwise {
…
}Except nobody wants to have to type @conditional and @otherwise, so the WG went in search of shorter names.
The Sass-savvy among you are probably jumping up and down right now, shouting “We have that! We have that already! Just call them @if and @else and finally get on our level!” And yes, you do have that already: Sass uses exactly those keywords. There are some minor syntactic differences (Sass doesn’t require parentheses around the conditional tests, for example) and it’s not clear whether CSS would allow testing of variable values the way Sass does, but they’re very similar.
And that’s a problem, because if CSS starts using @if and @else, there is the potential for syntactic train wrecks. If you’re writing with Sass, how will it tell the difference between its @if and the CSS @if? Will you be forever barred from using CSS conditionals in Sass, if that’s what goes into CSS? Or will Sass be forced to rename those conditionals to something else, in order to avoid clashing — and if so, how much upheaval will that create for Sass authors?
The current proposal, as I write this, is to use @when and @else in CSS Actual. Thus, something like:
@when supports(display: grid) and media(min-width: 33em) {
…
} @else {
…
}Even though there is overlap with @else, apparently starting the overall structure with @when would allow Sass to tell the difference. So that would sidestep clashing with Sass.
But should the CSS WG even care that a third-party code base’s syntax gets trampled on by CSS syntax? I imagine Sass authors would say, “Uh, hell yeah they should”, but does that outweigh the potential learning hurdle of all the non-Sass authors, both now and over the next few decades, learning that @when doesn’t actually have temporal meaning and is just an alias for the more recognizable if statement?
Because while it’s true that some programming languages have a when conditional structure (kOS being the one I’ve used most recently), they usually also have an if structure, and the two sometimes mean different things. There is a view held by some that using the label when when we really mean if is a mistake, one that will stand out as a weird choice and a design blunder, 10 years hence, and will create a cognitive snag in the process of learning CSS. Others hold the view that when is a relatively common programming term, it’s sometimes synonymous with if, every language has quirks that new learners need to learn, and it’s worth avoiding a clash with tools and authors that already exist.
If you ask me, both views are true, and that’s the real problem. I imagine most of the participants in the discussion, even if their strong opinions are strongly held, can at least see where the other view is rooted, and sympathize with it. And it’s very likely the case that even if Sass and other tools didn’t exist, the WG would still be having the same debate, because both terms work in context. I suspect if would have won by now, but who knows? Maybe not. There have been longer debates over less fundamental concepts over the years.
A lot of my professional life has been spent explaining CSS to people new to it, so that may be why I personally lean toward @if over @when. It’s a bit easier to explain, it looks more familiar to anyone who’s done programming at just about any level, and semantically it makes a bit more sense to me. It’s also true that I come from a place of not having to worry about Sass changing on me, because I’ve basically never used it (or any other CSS pre-processor, for that matter) and I don’t have to do the heavy lifting of rewriting Sass to deal with this. So, easy for me to say!
That said, I have an instinctive distrust of arguments by majority. Yes, the number of Sass developers who’d have to adapt Sass to @if in CSS Actual is vanishingly small compared to the population of current and future CSS authors, and the number of Sass authors is likely much smaller than the number of total CSS authors. That doesn’t automatically mean they should be discounted. It’s good to keep CSS as future-proof as possible, but it should also be kept as present-proof as possible.
The rub comes in with “as possible”, though. This isn’t a situation where all things are possible. Something’s going to give, and there will be a group of people ill-served by the result. Will it be Sass authors? Future CSS learners? Another group? Everyone? We’ll see!
Comments (18)
Learned CSS with Eric Meyer on CSS. Gone through CSS1, CSS2, CSS3, Less, Stylus, Sass with SCSS and SASS syntax. Who cares? Standards should be standard and should follow programming standards: if/else should be the way to go. In 15 years nobody will care anymoe about Sass. But everybody will write deep-level-nested .css files all along. This should be somehow implemented by the Sass guys, e.g. using comments like //sass:ignore-ifelse:on/off to disable and enable Sass functionalities while compiling.
I am reminded of the distinction between quirks mode and strict mode in HTML. CSS files don’t have anything like a DOCTYPE to use as a guidepost for this, and even that wouldn’t necessarily prevent those train wrecks.
This is a really interesting problem to be working on. I actually love the look of the @conditional syntax! I think it is very clear where I would anticipate I might be able to use @if for other truthy/falsey statements that are more broad.
Thinking about Sass users is a challenge but, in my opinion, a responsible and professional take to the situation. I’ll be excited to see this stuff hit browsers, that much is for sure.
Popular, albeit not top ranking, Javascript libraries have already been accepted as constraining how the language itself develops, so as to avoid breaking the web — see e.g. https://2ality.com/2022/03/naming-conflicts.html
That CSS has the same problem should not be a surprise; and the
when/elsesyntax seems like a sensible compromise.Doesn’t Sass only process .scss files? Wouldn’t it be possible for Sass to process @if in the language-appropriate way depending on the file extension? If it’s .css, treat it like CSS. If it’s .scss, treat it like Sass.
SASS took risk by “extending” CSS with its own CSS-like syntax.
They’ll just have to adapt their syntax somehow and the worst case scenario would be for them to to a (breaking) major release of the SASS/SCSS language, and provide some sort of migration scripts.
CSS should ignore SCSS and use the logical syntax @if and @else.
Would it help if CSS implemented both @if and @when as an alias? Then Sass can treat @if as it currently does, and Sass users can opt in to the CSS version by only using @when.
Sass can keep their @if/@else, and use something like @cssif/@csselse to represent the CSS version. After all, if you are using Sass, you are writing .scss or .sass files, not .css files, so you have to follow Sass rules.
It’s not like SASS has never changed their syntax (@import / @use anyone? Namespaces?). CSS is a standard. SASS argues that valid CSS is valid SASS. It seems to me the onus is on them. If SASS wants to keep @if & @else I believe disambiguating them is their task. SASS outputs CSS. Not the other way around.
I like the suggestions of aliasing CSS’s if/else to cssif/csselse.
Alternatively, SASS could support a pragma in the file directing it as to how to interpret if/else. But the aliasing option seems like it would produce the least breakage.
A standards body should not at all care about whether a third party has a conflicting implementation. The standards process takes enough time to where Sass or others could create a new version that fixes any conflicts in good enough time to prevent problems.
Using “when” would be a break from pretty much all other programming conventions instead of using the if/else pattern.
Also, I thought part of the rationale for libraries / higher level versions of a language like Sass were to create new features that at some point were upstreamed to the standards for the language being altered. Perhaps the convention/implementation won’t be exactly as it is in Sass but having it implemented into the standard should be seen as a win for the Sass project.
I wondered why, rather than the other commenters aliasing, not to use the minor but important syntactic difference of parentheses on the conditional test?
In that way SASS can distinguish between its own @if without parentheses and CSS @if with parentheses.
This is a very different situation from past conflicts in JavaScript. SCSS is compiled. The current version of the compiler will never produce a native @if and will always produce valid CSS. The next version of the compiler should either remove support for any conflicting syntax or introduce an alternative syntax if they see enough benefit in the non-native features.
Whether a preprocessor produces the expected output is not the concern of the standards body. It is expressly the concern of the developer and the compiler.
A standards body can only guarantee backwards compatibility with it’s own specifications. It has no power over nor any obligation to a third party compiler.
Echoing most of the thoughts here: by all means, the CSS Working Group should not concern themselves with what third-party projects have done. The onus should be on the Sass project to adapt, not for CSS syntax to bend over backwards to avoid a clash. I’m dismayed that the current proposal is for
@when.As an everyday Sass user I think it’s a bit selfish how the preprocessor stands in the way of adopting convention.
Here’s what the Sass team can and arguably should do:
Deprecation notice on
@ifto use@when(just like they did with slash-division which is a lot more tricker for users to migrate to).User upgrades Sass. User compiles and see that his styles look broken. User reviews terminal and sees a notice:
“
@ifis now treated as a native construct by Sass. Please replace any previous usages of@ifto@when.”Anyone with half a brain would then do a Find and Replace operation and merrily move on.
If the Sass team worries about backwards compatibility, then they can create a new
@use-legacyand@import-legacyor some other way to tell the compiler to transform and treat@ifto@whenon import.I would rather we roll up our sleeves for 5 minutes, Sass help out and provide a way to read “old” libraries with
@ifas@when, so that we can keep with conventions and use@if. Let’s not make our short burden a bitter taste for future CSS users who probably won’t even be using Sass.All popular articles out there will be updated to use
@whenin their example as users badger them to do so, and many of the ones that don’t get updated will have users leaving comments about it anyway.Pingback ::
Weeknotes 22:11 | Jeff Bridgforth :: Front-end developer in Chattanooga, Tennessee
[…] When or if – Eric Meyer discusses a current debate on what to name a conditional structure in the CSS Working Group. […]
Pingback ::
If of when (CSS), snel een kleurenpallet opstellen en een opmerkelijk vacature bij de Nielsen Norman Group - Pixel Paranoia the Podcast - Dé podcast over UX, UI en Front-end development
[…] 0:50 – CSS if of when – https://meyerweb.com/eric/thoughts/2022/03/14/if-or-when/ […]
Several years ago (yes, this argument over @if/etc has been going on for years), it was stated that SASS was perfectly willing to change their own syntax as needed if it conflicted with the CSSWG syntax. Is this not still the case?
There’s of course the irony that if they’d settled on a choice 5+ years ago, the dustup from SASS or other preprocessors would have long since cleared up, and this nonsense would be fixed by now.