New principle: Do not design around third-party tools unless it actually breaks the Web

[LeaVerou]

This was brought up in the CSS WG's discussion of @when vs @if: w3c/csswg-drafts#112

@when was chosen over the far more common @if to avoid conflicts with Sass, a CSS preprocessor.
Web Platform technologies need to last for decades, and should not be designed around third party tools that just happen to be in use at the time, unless it is absolutely necessary because it breaks the Web (e.g. array.contains() that TC39 faced).

[kenchris]

We should only use alternative (worse) names/keywords in the case that using the preferred word would actually break existing live content. I believe that we are talking about a preprocessor in this case, so I would prefer to not use an unusual name like @when and instead use the more common @if

[tabatkins]

I strongly object to this as a principle. If adopted as-is it would encourage terrible stewardship of the web.

The web doesn't consist solely of browsers. All the tools that are used to author the web are part of the authoring experience. Browsers are the most important part of that experience: they have the largest audience and the longest history and future. But that doesn't make them the sole part of it, and willfully breaking widely-used tools in drastic, disruptive ways needs to be balanced by a correspondingly large benefit to authors in general, or by showing that we're avoiding a correspondingly large harm to the feature and its future users.

For example, in the issue that's inspiring this, Sass is the most widely-used CSS preprocessor in the world, used directly or indirectly by a fairly high % of all web authors. @if is one of the most widely used rules in Sass, appearing in nearly all Sass stylesheets, either directly or indirectly via libraries using the feature. Adding an @if to CSS with a substantially different processing model would constitute immense harm to this population of web authors. The benefit (or avoided harm) of using @if over another reasonable name cannot reasonably be argued to counterbalance that harm.

(I'm not litigating that issue here; I'm merely providing it as an example.)

A substantially weaker version of this principle would be acceptable, codifying the good practice of valuing browsers and the future web higher than existing tooling (and proportional to usage/harm), but not infinitely so.

[Marat-Tanalin]

It’s not about browsers. It’s about that standards are long-term and cannot be changed, while tools are temporary and can adapt to standards. Moreover if the tool authors explicitly expressed their willingness to adapt and asked for not making spec-related decisions based on the current tool features/syntax.

Standards should not be designed in a less right way just on the ground of preventing conflicts with tools, regardless of how widely a specific tool is used.

[nex3]

If adopted, this principle would dramatically harm web developers and damage the health of the web ecosystem as a whole. It’s absolutely true that “platform technologies need to exist for decades”, and as Tab points out tools are intrinsically part of a healthy and usable platform. Sass has existed for more than half of CSS’s lifespan (when Sass was first released, no browser fully supported hsl()!) and it’s more popular than it’s ever been. Tools like Sass persist over the long term to solve critical use-cases that are always going to exist, so it’s a mistake to think that they’re so much less permanent or more mutable than the underlying platform that they can be categorically ignored.

(For context: I am the lead designer of Sass.)

Symbiosis

Sass and similar tools exist in a symbiotic relationship with the CSS specification. Sass compiles to CSS, and in turn makes CSS more appealing for authors who need to manipulate and share styles. Sass comes up with new features that aren’t in CSS, and in turn inspires new CSS features such as variables, nesting, math functions, and color manipulation. This relationship is good for CSS authors because it allows them to articulate their intentions while still writing in a language that is CSS at its core. It’s good for the web because it allows CSS to meet the encapsulation and re-usability needs of large-scale users without abandoning core strengths of the language as with CSS-in-JS, and because it shows which avenues for feature growth are actually useful to users without needing to commit to implementing them in browsers.

There are two key aspects of Sass that make this symbiosis work. First, Sass is a CSS superset. We go to tremendous lengths to ensure that all valid CSS is also valid Sass, and because of this Sass authors think of their stylesheets in terms of the CSS they’ll generate. This means that Sass authors are CSS authors, so harming Sass authors harms your own users. What’s more, intentionally introducing incompatibilities between CSS and Sass pushes Sass into a position of being a different language than CSS and thereby muddies users’ understanding of CSS itself.

The second symbiotic aspect is that Sass’s new features are CSS-y. We make a strong effort to make the syntax and (where it makes sense) the semantics of Sass-specific features work well with the way CSS thinks. Sass is much more than just a C-style preprocessor: it speaks the language of CSS natively, which is why features like nesting and color manipulation port so well to plain CSS. Even variables, which had to work procedurally in Sass, use a declaration-style syntax specifically to feel at home in a CSS world. But if Sass features are CSS-y, it means we’re trusting you as the CSS team not to use that exact syntax to mean something completely different.

Historically, Sass has been very willing to change to get out of CSS’s way. We changed how we parsed custom properties; we added special casing to support min() and max(); we’re moving away from using / as a division operator because CSS uses it as a separator, despite the fact that this causes our users tremendous dismay; and we even have a plan in place to avoid conflicts with CSS nesting. But to deprecate and rename @if, one of the most widely-used Sass features that does something completely different than the proposed CSS feature, would cause more pain and chaos than all of these put together. We’ve always been happy to compromise with CSS. All we’re asking is that CSS also on very rare occasion be open to compromising with us.

What would this principle mean for CSS tools?

If the proposed principle were adopted, it would be a clear signal to Sass and any other CSS tool that we cannot trust any syntax that looks like CSS to be safe from future conflicts. This would leave us with no option but to abandon one of our symbiotic aspects, either of which would be extremely bad:

1. We could give up on making Sass features CSS-y and change our syntax to something unlike CSS to avoid this and future conflicts. For example, instead of at-rules, Sass may have users write ~if ... and ~include .... This would impose a migration cost on our users higher than anything we’ve asked of them before, and almost certainly leave many of them pinned to older versions of Sass that don’t support plain-CSS @if. Worse than that, it would mean that all the tooling that’s based on modified CSS grammars wouldn’t work anymore. This is already bad for Sass users who often use CSS-based parsers for linting and formatting, but it’s even worse for users of PostCSS-based extensions who inherently rely on a CSS grammar for parsing.

2. Give up our principle of remaining a CSS superset. This would require no change from our users and minimal change in the Sass implementation, so it may be the road we’d be forced to go down, but it’s no less catastrophic in the long term. It means that Sass authors are no longer really writing CSS, they’re writing a custom dialect that targets CSS as a build target. And the more CSS conflicts with Sass, the more different these dialects become.

I suspect that many CSS purists may feel that Sass is already a custom dialect and so these changes are scarcely a loss, but that’s based on a misunderstanding of what Sass (and tools like PostCSS) are trying to do. Unlike some styling solutions, Sass has never been an attempt to replace CSS. We cling so firmly to our symbiotic principles precisely because we believe that CSS is an excellent way to conceptualize and represent styles. Sass aims to allow this representation of styles to be made into libraries that can be customized and shared, but users are always engaging with it the same way they engage with CSS because CSS is at its heart. Please don’t make us cut that heart out.

[tabatkins]

It’s about that standards are long-term and cannot be changed, while tools are temporary and can adapt to standards.

This hits my point about browsers not being the sole player in this space.

Standards can be changed, and regularly are. The limitation is just compat pain: how much will it hurt users when pages using the old version of the feature break; how much will it hurt authors who'd already written code against the old feature and now have to rewrite.

Those same questions are exactly as valid for any tooling. Sass happens to just be an author-level tooling, since it runs server-side, but other CSS-modifying libraries run on the page, so both author and user concerns are valid here. By definition, these populations will be smaller than the set of all users of browsers, but they're often not insignificant.

Asserting that we don't need to care about those at all is just as wrong as saying compat pain for any other web feature doesn't matter.

[davidkpiano]

If you don't want to choose @when just because it'll break a 3rd-party tool, choose @when because it makes more sense in a declarative (stylesheet) setting.

The popularity of the term @if is actually a detriment. As a web developer, when I see an if, I think of side-effects being executed, as if it were part of running code:

if (some condition) { (execute this content) }

Whereas a @when reads more like:

Here are the chosen constraints @when this is true

I would actually consider it a mistake if CSS adopted control flow keywords as syntax for something that has nothing to do with control flow.

[mirisuzanne]

Almost every decision we ever make in the CSSWG is based on a balance between some ideal long-term syntax, and the compatibility & migration pain that might be caused for authors. That has always been a balancing act, and always will be. In fact, it's the first principle of this organization that author pain should be considered above theoretical purity:

User needs come before the needs of web page authors, 
which come before than the needs of user agent implementors, 
which come before than the needs of specification writers, 
which come before theoretical purity.

Yes, Sass can ship changes. And that would result in a massive number of web authors & teams who need to entirely re-tool their site architectures just to keep using CSS. That's bad for everyone involved, and should happen as rarely as possible. Meanwhile, as pointed out by @davidkpiano, there are other good alternatives here, and other tradeoffs worth considering. It feels agressive to imply that there's a clear-cut, all-or-nothing, platform purity principle here which suddenly outweighs all those considerations.

[Marat-Tanalin]

Yes, Sass can ship changes. And that would result in a massive number of web authors & teams who need to entirely re-tool their site architectures just to keep using CSS.

SCSS could, for example, just add a new internal at-rule like @css-if that would translate to native CSS @if, while the existing internal SCSS’ @if would continue working with 100% backward compability with existing SCSS code.

[Marat-Tanalin]

@nex3 Some TLDR would be useful.

[phun-ky]

Sass authors are CSS authors

I do not agree to this statement. To be able to write any preprocessor style, you FIRST need to know CSS. That's like saying I'm a baker, but all I do is to reheat frozen buns.

CSS should not adapt to Sass/Scss, it should be the other way around.

I don't see Java change stuff for Kotlin, or Javascript change things for React. Do you?

Regarding which keywords or the nomenclature for conditional statements or control flow, I don't care as long as it is sane and make sense. ALL preprocessors needs to adapt to the specs and principles of CSS.

I admit that Scss have been visionary in their syntax and tooling, but they also need to do it properly.

To be clear, do not design around third party.

[KittyGiraudel]

I don't see Java change stuff for Kotlin, or Javascript change things for React. Do you?

Except JavaScript specification proposals did in fact change because of existing frameworks. Not React in that case (although we do sure like it to be the usual scapegoat in the frontend industry), but MooTools. See this post for more information about what happened and how the TC39 eventually adapted to the existing ecosystem instead going ahead and recklessly breaking it for the sake of dogmatic purity.

I admit that Scss has been visionary in their syntax and tooling, but they also need to do it properly.

That’s such an awkward point to make. The @if directive from Sass has been there for 13 years now, while the CSS proposal is a few years old at most. I’m not quite sure what “they also need to do it properly” even means in that instance. Natalie has gone to great lengths to explain the design choices behind Sass features over the years. Nothing was done “improperly”—whatever that means.

ALL preprocessors needs to adapt to the specs and principles of CSS.

That’s an overly simplistic view of the situation. Some legitimate concerns have been raised in that conversation about what a conflict between Sass and CSS would imply, and just saying “well Sass (and its authors) should just deal with it” is not helpful in the resolution of the problem at hand (and similar future problems). It’s a massive ecosystem that spreads over a decade of use. You can’t just shrug at it. Doing so is as silly as suggesting that introducing a JS feature that would conflict with existing jQuery syntax (as an example) is solely jQuery’s maintainers problem, and theirs to fix. It's not.

It feels agressive to imply that there's a clear-cut, all-or-nothing, platform purity principle here which suddenly outweighs all those considerations.

This very point from @mirisuzanne. Anyone making blanket statements of the like of “well tough shit, just go ahead with CSS syntax without considerations for the existing surrounding ecosystem” is either not engaging in good faith into the discussion, or being willingly dismissive of people whose job it is to care for said ecosystem and its implications at large.

[niaccurshi]

It feels agressive to imply that there's a clear-cut, all-or-nothing, platform purity principle here which suddenly outweighs all those considerations.

I think this by @mirisuzanne gets to the core of this discussion better than just about anything else. There are people here discussing as if CSS has to "change", the reality is that it doesn't have to change anything, it merely has to start differently. It is an initial choice being made that can either still make sense as something like @when and be taught as a new tool in CSS' arsenal, or can fundamentally and aggressively force other widely used tools to change for the sake of trying to use a common and most pure syntax for conditional statements.

In this regard I agree with @davidkpiano in that css isn't a procedurally run code set, and using @if is actually more likely to cause people to be confused when it doesn't cause the output they would expect

I understand this is quite specific to one example, as the discussion has been, when talking about a design principle; however I think this shows that "as long as it doesn't break the web" is too low a bar as a principle given the complexity of environment CSS already exists within. Changes have to respect real world context.

[Marat-Tanalin]

the CSS proposal is a few years old at most.

Fwiw, the if/else CSS thing is being discussed for 5 years already.

[rik]

I'd like to propose another principle: Provide ways for third parties to extend a language and stay valid. Help third party tools to not get in the way of future specifications by having clear rules that can be verified by a validator.

HTML requires custom elements to use a dash and custom attributes to start with data-. CSS seems to have the - prefix but I'm not sure it's a recommended way to extend CSS after the vendor prefix era.

If Sass had been encouraged to use @-if or @-sass-if, this wouldn't be an issue. It's too late for the particular issue at hand but it could help in the future?

I think it would also help authors to differentiate which parts are from the original language and which parts are from the third party tool.

[malchata]

Seconding @when over @if for the reasons that @davidkpiano outlined. CSS is declarative, and in a declarative context, controlling how styles are applied via @when scans better than @if. Alternatives to traditional conditional statements exist even in non-declarative programming languages. For example, Perl offers the relatively unusual conditional statement unless, which executes a block if the condition is false. This leads to more readable code in some situations (e.g., unless this piece of data already exists in a memory cache, retrieve that data from a remote data store and then write it to the memory cache).

From the third party tooling perspective, I don't agree with the notion that impinging on SASS's implementation of @if is an example of the direction web standards should proceed. It puts the maintainers of the tool in a quandary of how to parse the (hypothetically) standardized @if syntax — should it be preserved as valid CSS rather than transformed? Can that be done without significant developer or even user-facing consequences? @when addresses this problem in a way that doesn't compromise readability or compat with existing tooling.

[tabatkins]

Fwiw, the if/else CSS thing is being discussed for 5 years already.

And it's been called @when/@else for virtually that entire time, because this exact issue was brought up early.

[mikemai2awesome]

First of all, love and hugs. I see a lot of awesome people here. Secondly, I would love a bit more context, seems like the comments here (and Twitter threads) are arguing about different points.

Is the CSS spec choosing @when over @if because:

1. It actually makes sense and describes what it does
2. Or simply to avoid conflicts with Sass

If it's 2, that's really hard to agree with. From a standards and conventions point of view, I think that sets a bad precedent. It will lead to other makers of 3rd party tools to think "well, if we are popular enough, the CSS spec will just design around us". I know Sass isn't just an ordinary 3rd party tool, so it's even more important for them to lead by example. Breaking changes are hard to deal with, but whoever chooses to use a third party tool has the responsibility to adapt changes.

If it's 1, then it would be a different debate. It is no longer about the point of this thread: "Do not design around third-party tools". Perhaps that warrants a separate discussion. Probably one that should happen first. I've only found some examples by @tabatkins, looking at those does not lead me to think this MUST be named @when. Writing @if instead would still make the most sense since it's a common pattern. Am I missing something?

[nex3]

If it's 2, that's really hard to agree with. From a standards and conventions point of view, I think that sets a bad precedent. It will lead to other makers of 3rd party tools to think "well, if we are popular enough, the CSS spec will just design around us". I know Sass isn't just an ordinary 3rd party tool, so it's even more important for them to lead by example. Breaking changes are hard to deal with, but whoever chooses to use a third party tool has the responsibility to adapt changes.

This is an oversimplification. The precedent has already clearly and repeatedly been set that Sass will adapt to new CSS features in almost every circumstance. To quote myself:

We changed how we parsed custom properties; we added special casing to support min() and max(); we’re moving away from using / as a division operator because CSS uses it as a separator, despite the fact that this causes our users tremendous dismay; and we even have a plan in place to avoid conflicts with CSS nesting.

We also go to great lengths to avoid possible conflicts with CSS. Back when we added @if (along with rules like @while and @for) in 2008, we believed them to be safe because they were so clearly associated with procedural control flow, and CSS was a declarative language that strongly tended to use declarative rather than imperative keywords. No one comes into this expecting CSS to bend for them rather than vice versa.

The crux of the issue is that if there is absolutely zero room for saying "please make a small change in a CSS draft with zero migration costs to avoid forcing a huge change to Sass with massive migration costs", if that's an argument that's forbidden on principle, that effectively invalidates the entire premise on which Sass exists. We can't make a CSS extension language that's compatible with plain CSS if there's absolutely zero space for us to add extensions that we can reasonably trust will be safe over time.

Again, I want to emphasize here that Sass tries very hard to proactively avoid these conflicts. But this proposal punishes us for doing so: by saying "no matter how much effort tools put into remaining compatible with CSS and avoiding future conflicts, if you guessed wrong or we change our mind we will break you without a second thought," the TAG would tell authors that all their compatibility efforts are wasted. At that point, why even bother trying to be compatible?

[Marat-Tanalin]

@nex3

The crux of the issue is that if there is absolutely zero room for saying "please make a small change in a CSS draft with zero migration costs to avoid forcing a huge change to Sass with massive migration costs", if that's an argument that's forbidden on principle, that effectively invalidates the entire premise on which Sass exists.

Existing sites could continue using older versions of the preprocessor. Zero migration costs.

We can't make a CSS extension language that's compatible with plain CSS if there's absolutely zero space for us to add extensions that we can reasonably trust will be safe over time.

SCSS and other preprocessors could be 100% forward-compatible by using prefixed at-rules like @-if or @_if instead of @if. That’s actually the only way for forward compatibility with standard CSS. What sounds logical at the time of introducing a feature into a preprocessor does not guarantee anything if the non-standard feature of the preprocessor uses the standard CSS syntax.

[Marat-Tanalin]

@tabatkins

Fwiw, the if/else CSS thing is being discussed for 5 years already.

And it's been called @when/@else for virtually that entire time, because this exact issue was brought up early.

I was talking about the whole fundamental conditional thing, not the specific syntax.

[j9t]

One way of looking at this is that it should have been clear to the Sass team (and perhaps to Sass users) that Sass syntax inventions could eventually clash with CSS.

This risk, and awareness for this risk, seems to be missing (at least in this thread).

That this here was to happen was not a matter of if, but when. (Oof.)

While one may be empathetic about the popularity of Sass and “just” have a core standard of the Web yield, that may also set a dangerous precedent, signaling that tool authors do not need to think about the consequences of their work as long as it’s successful (i.e., popular). This does not seem healthy or useful.

---

On the more pragmatic side, to what degree can we assume that CSS authors who make use of the latest CSS features do also keep their CSS tooling up-to-date?

That is, if Sass was to move to an alternative to their @if, could we avert the worst case by allowing as many Sass authors as possible to switch to the new syntax while the CSS side is spec’ed and implemented? (Those who do keep working with older Sass tooling may well not use the newest CSS features.)

In other words, does this have to end in disaster or could we make @if work in CSS, while allowing Sass to look into an alternative?

[plinss]

@nex3

We can't make a CSS extension language that's compatible with plain CSS if there's absolutely zero space for us to add extensions that we can reasonably trust will be safe over time.

CSS has had an extension mechanism since the 90s, specifically for this purpose, vendor prefixes. Sass could, and should, have been using this mechanism for every extension. e.g. @-sass-if, or even @-if would have avoided the @if/@when issue entirely.

[atanassov]

Fascinating conversation with so many great points being made. It seems however that we are straying away from our initial intent. Perhaps the specific example we used (Saas being the 3rd party tool, CSS and how @if/@when evolved etc.) sparked a conversation that is too myopic, taking us away from the principle in need. The design principle is about platform capability layering, external extensibility guidance and general advice on how we need to assess existing patterns between API layers, in particular tools.

Layering approach

In the broadest terms, capabilities of the Web platform do not take a dependency on external libraries or tools intended to extend or enrich such capabilities. These dependencies can be either syntactic or functional. We think of these as upper-layer dependencies.

The same principle applies when we expose lower-layer OS/platform capabilities to the Web. There we are the ones who are not in position to demand/dictate API shape, capabilities or even uniformity between different OS/platforms.

API design with layering

When designing Web capabilities, we consider user needs, use cases, pain points/opportunities, and existing upper layer patterns such as libraries or tools (especially the popular ones) that can benefit from lower layer implementation. Bringing these capabilities to the Web platform usually results in improved consistency, availability, performance, accessibility, reliability, and ideally interoperability.
We work to design the capabilities through the standardization process and along the way document best practices. In the case of API layering, we added guidance for that are part of the Web (see. https://w3ctag.github.io/design-principles/#high-level-low-level) and this issue is about the layers outside of the Web platform.

The specific example

The example we used was intended to demonstrate a syntax collision with an upper layer library/tool capability desirable to the Web layer. This must be avoidable through language extensibility (as pointed out by @plinss #335 (comment)) or changing the Web API syntax due to popularity of the feature.

All in all, this is an example used for illustrative purposes. If you want to continue this specific conversation, with my CSSWG co-chair hat on, I would like to invite you to https://github.com/w3c/csswg-drafts where we can debate the past, current, and future of it. Here our focus is general platform design principles guidance, and I hope we can focus the conversation back to it.

[ianthedev]

Maybe implementing both @if and @when and making them synonyms of each other can solve the problem. By doing that, developers who use Sass can choose to use @when.

[LeaVerou]

As @atanassov has mentioned, let's please keep the @when vs @if discussion in csswg-drafts. Since there was no open issue about this, I opened one.

This discussion (and general repo) is about broader discussion of Web architecture principles. While this issue was prompted by @when vs @if, it is not limited to this particular design decision, or even CSS.

[mirisuzanne]

I think it's important to note here that everyone has generally agreed on the idea that there is a reasonable layering of priorities here. The sticking point is in implying that such an order of priorities can be applied all-or-nothing, where concerns from the ecosystem can be entirely ignored when adding to the web platform — rather than simply taking priority into account as we discuss tradeoffs (which is already the assumption in every syntax conversation I've ever been part of).

And I honestly don't believe that anyone would be willing to apply such an all-or-nothing rule universally. While @LeaVerou is pushing for it in relation to @when/@if, she is also raising ecosystem concerns on other issues. See, for example w3c/csswg-drafts#581 (comment):

My only objection is semicolons. Introducing semicolons in CSS is going to break a lot of highlighters, naive parsers etc, even scanning of single-line CSS by humans and we should try to avoid it.

Those are ecosystem concerns. And I agree with Lea that they are issues we need to consider (and the detailed discussion of it should happen on that thread, not here).

But I'm very worried about this new principle being implied as an all-or-nothing rule in some cases, while merely a preference in others — based entirely (it seems to me) on how much TAG members like or dislike the syntax in question.

[mirisuzanne]

Thank you @LeaVerou - that is exactly the nuanced clarification I was hoping for.

[tabatkins]

Yes, that is also the nuanced statement I am happy to accept. It is notably weaker than what was stated in the OP. ^_^

[LeaVerou]

Yes, that is also the nuanced statement I am happy to accept. It is notably weaker than what was stated in the OP. ^_^

I'm happy we are on the same page, but I honestly don't think my latter statement is weaker. The original statement was just more terse, and thus easier to fill in any blanks with assumptions, but I have not changed my mind on anything. E.g. in the example that started this thread, I do think that @when does have significant usability drawbacks over @if, it's not just another option with near-identical usability. But I'm happy that we agree in terms of general principles, even if we disagree on the specific examples, as we can resolve the latter in the CSSWG.

[LeoniePhiline]

Automated tools will make migration entirely painless for users of affected third party tools.

We live in a modern development world full of tokenizers, parsers, compilers, formatters, pretty printers. Auto-namespacing or otherwise renaming clashing token names in developer-facing code is no big deal nowadays.

Web standards must be solid and make the best choices. Tools come and go, tools are easy to adapt. Standards are forever.

[nex3]

Automated tools will make migration entirely painless for users of affected third party tools.

This is simply not true. Even simple migrations are very expensive at scale, and migrations that require users to update to the latest version of tools to avoid naming conflicts are an order of magnitude more expensive than that. It's no exaggeration to say that, for example, migrating Sass users away from @if would conservatively cost millions of dollars of engineer-time.

[Marat-Tanalin]

@nex3 Do you have some proof stats? ;-)

[LeoniePhiline]

@nex3
Millions of dollars to replace @if by something properly namespaced? That's a simple search & replace. There is not even the need for a regex.
Tool versions are locked in package lock files. It's a matter of a few minutes and a commit & push.

[ianthedev]

If you don't want to choose @when just because it'll break a 3rd-party tool, choose @when because it makes more sense in a declarative (stylesheet) setting.

Please check the following code:

@when supports(display: grid) {

} @else {

}

The @when in the code above literally implies that a browser only supports grid at a certain time and not at other times, and that makes no sense.

[LeoniePhiline]

@ianthedev Could you move/repost that at the case-specific issue? ➡️ w3c/csswg-drafts#6684

[ianthedev]

@LeoniePhiline Thanks for reminding me. I just did it.

[DennysDionigi]

I will go for a @while.

@while media(max-width: 768px) {
@while (prefers-color-scheme: dark) {
//dark mode on mobile device
} @else {
//light mode on mobile device
}
}

Something like: starting from this condition and while it's effective do this.

In the following case seems something that needs to run only once, as said above.

@when supports(display: grid) {

} @else {

}

Btw, you got the key. Sass or not.

[LeaVerou]

@DennysDionigi Please post CSS design suggestions in the relevant issues in the csswg repo, in this case w3c/csswg-drafts#6684

[matthew-dean]

That’s such an awkward point to make. The @if directive from Sass has been there for 13 years now, while the CSS proposal is a few years old at most.

I think this is succinctly addressed by:

One way of looking at this is that it should have been clear to the Sass team (and perhaps to Sass users) that Sass syntax inventions could eventually clash with CSS.

This risk, and awareness for this risk, seems to be missing (at least in this thread).

Less / Sass / PostCSS are probably all guilty of making the same mistakes while creating "supersets" of CSS. CSS actually has a mechanism / naming pattern for "custom" identifiers, which is the dash -.

So, if Sass manages to dodge a bullet if this proposal uses @when, it would be wise for Sass to deprecate current at-rules in favor of @-if @-else @-for @-each etc, for example. (Or $if $else $for $each like other CSS pre-processors are doing) Address it now in the Sass ecosystem before this comes up again.

[carlosmintfan]

I will go for a @while.

@while media(max-width: 768px) { @while (prefers-color-scheme: dark) { //dark mode on mobile device } @else { //light mode on mobile device } }

Something like: starting from this condition and while it's effective do this.

In the following case seems something that needs to run only once, as said above.

@when supports(display: grid) {

} @else {

}

Btw, you got the key. Sass or not.

You've pinged the GitHub user accounts @when, @while and @else by this LOL. Use the formatting options the GitHub comment editor provides to mark them as code :)