related: #7873

Hi @portikM,

Out of curiosity, can you give a real world example where you really need/want declarations after nested rules?

So you really need this:

.example {
  color: red;

  a {
    font-weight: bold;
  }

  font-weight: normal;
}

But can't rewrite to:

.example {
  color: red;
  font-weight: normal;

  a {
    font-weight: bold;
  }
}

The CSSWG thoroughly checked this to make sure it wouldn't cause issues on existing sites and found that in practice CSS authors didn't write declarations after rules in a way that actually affected the outcome. As is also the case in your example.

I am not sure why Sass is giving the guidance to use & {} when moving the declarations seems like a simpler way to resolve this issue.

Hi @portikM,

Out of curiosity, can you give a real world example where you really need/want declarations after nested rules?

So you really need this:

.example {
  color: red;

  a {
    font-weight: bold;
  }

  font-weight: normal;
}

But can't rewrite to:

.example {
  color: red;
  font-weight: normal;

  a {
    font-weight: bold;
  }
}

The CSSWG thoroughly checked this to make sure it wouldn't cause issues on existing sites and found that in practice CSS authors didn't write declarations after rules in a way that actually affected the outcome. As is also the case in your example.

I am not sure why Sass is giving the guidance to use & {} when moving the declarations seems like a simpler way to resolve this issue.

The screenshots I attached is actually a real world use-case for this. 100% of impacted lines I've fixed over past couple days since we started using Sass 1.77.7 were declarations that follow one or more mixins. Often times we'll have some generic mixin that comes with nested rules and then we'll want to override/extend that mixin with some specific to use-case declarations. High-level example:

@mixin genericButtonMixin {
  background-color: transparent;

  .icon {
    stroke: currentColor;
  }
}

button.primary {
  @include genericButtonMixin;

  background-color: blue;
  color: red;
}

There's also a case for automatic migration tools on big codebases to avoid introducing regressions.
e.g. https://sass-lang.com/documentation/cli/migrator/

Ah, yes, with mixins you can write an at-rule that actually represents both declarations and/or more rules. This is also the primary reason that the CSSWG changed the behavior of nesting, they work in a more interesting way when nested rules and declarations preserve their order. Unfortunately native nesting is different from how Sass works.

I get that Sass wants to provide a way for CSS authors to opt-in to the standard CSS mechanics today and that writing & {} is a clean way to get this. Even when the same code written as standard CSS wouldn't really make sense. It isn't wrong, but just needlessly verbose.

But eventually Sass will update and work like native CSS for all nested delcarations and you will no longer need to write & {}, correct?

So if we add a plugin option to help Sass authors it will only be briefly useful.

Is there a wider use case for ignoring & {} specifically?

Have there been requests to ignore specific selectors or patterns for this rule? I couldn't spot any.

Is it better to use configuration comments to disable this rule in very specific cases?

related: #2198 (comment), #2199

I agree with @romainmenke. If this pattern helps only developers using Sass, it would be against our rule criteria:

Also, this issue is related to stylelint-scss/stylelint-scss#1020. The stylelint-scss repo seems more suited for this discussion.

How do I solve this:

@mixin col-2($defaultSpan: 1) {
    @include grid-layout();
    grid-template-columns: repeat(auto-fit, minmax(40%, 0.5fr));
    > * {
        grid-column: span $defaultSpan;
        @include breakpoints.tablet() {
            grid-column: span 1;
        }
    }
    .half-width {
        grid-column: span 1;
    }
    .full-width {
        grid-column: span 2;
    }
    @include breakpoints.mobile() {
        grid-template-columns: 1fr;
        .full-width {
            grid-column: span 1;
        }
    }
    @include browserhacks.ie_only {
        .half-width {
            width: 50%;
        }
        .full-width {
            width: 100%;
        }
    }
}

│ Module Warning (from ../.yarn/__virtual__/sass-loader-virtual-42d1bf09a7/4/.yarn/berry/cache/sass-loader-npm-16.0.2-eafa07389f-10c0.zip/node_modules/sass-loader/dist/cjs.js): │ Deprecation Warning on line 55, column 4 of file://src/css/layout/_grid.scss:55:4: │ Sass's behavior for declarations that appear after nested │ rules will be changing to match the behavior specified by CSS in an upcoming │ version. To keep the existing behavior, move the declaration above the nested │ rule. To opt into the new behavior, wrap the declaration in& {}. │ │ More info: https://sass-lang.com/d/mixed-decls │ │ 55 | grid-template-columns: repeat(auto-fit, minmax(40%, 0.5fr)); │ │ │ src/css/layout/_grid.scss 56:5 col-2()