https://meyerweb.com/eric/thoughts/2022/03/14/if-or-when/ meyerweb.com Main content Navigation links Footer * Post Archives * CSS Work * Toolbox * Writing * Speaking * Other Stuff * About this site When or If Published 6 hours past The 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! * When or If was published on Monday, March 14th, 2022. * It was assigned to the CSS, Standards, and Tools categories. * There have been five replies. --------------------------------------------------------------------- Comments (5) 1. 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. Signed, Max Monday, March 14th, 2022 1:03pm 2. 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. Signed, Adam Rice Monday, March 14th, 2022 2:05pm 3. 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. Signed, Helen Monday, March 14th, 2022 2:19pm 4. 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/else syntax seems like a sensible compromise. Signed, Steve Monday, March 14th, 2022 3:42pm 5. 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. Signed, Cameron Eagans Monday, March 14th, 2022 4:24pm Add Your Thoughts * Trackback URL * Comments RSS feed' Name [ ] E-mail (required but not displayed) [ ] URI (optional) [ ] Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand. HTML allowed: 
 

---------------------------------------------------------------------
Your Comment (Markdown supported) 
[                                                                      ]
[                                                                      ]
[                                                                      ]
[                                                                      ]
[                                                                      ]
[                                                                      ]
[                                                                      ]
[                                                                      ]
[                                                                      ]
[                                                                      ]

[Post your e-pistle] if you're satisfied with it.

Comment Preview

 [                                             ] 
 [                                             ] 
 [                                             ] 
 [                                             ] 
 [                                             ] 
 [                                             ] 
 [                                             ] 
D[                                             ] 

Browse the Archive

No, Apple Did Not Crowdfund :focus-visible in Safari

Related Posts

  * Back in the CSSWG June 8, 2021
  * Ancestors and Descendants June 2, 2021
  * 25 Years of CSS May 25, 2021
  * CSS Naked Day 2020 April 9, 2020
  * CSS Specification Timelines, Updated and Modernized March 3, 2020
  * Color Easing Isn't Always Easy April 25, 2019
  * CSS4 Color Keyword Distribution Visualization March 29, 2019
  * Grid Inspection March 8, 2017
  * CSS Grid! December 5, 2016
  * Workshopping September 28, 2016

Browse posts in the CSS, Standards, or Tools categories.

Feeds

A dispatch of all posts to "Thoughts From Eric" is available in both
RSS 2.0 and Atom.

Identity Archipelago

  * Twitter
  * GitHub
  * Flickr
  * Dribbble
  * Facebook
  * LinkedIn

The excuse of the day is

nobody forwarded that memo

All contents of this site, unless otherwise noted, are (c)1993-2022
Eric A. and Kathryn S. Meyer. All Rights Reserved.
"Thoughts From Eric" is powered by WordPress. Most of the rest of the
site is hand-authored.
The ink-sketch images used in this site's design are adapted from
Yuzan Mori's Hamonshu, Volumes 1-3, published in 1903 and made
available for public use by the Smithsonian Libraries and the
Internet Archive.