Breaking Change: Invalid Combinators

Sass has historically supported three invalid uses of combinators:

• Leading combinators, as in + .error {color: red}.

• Trailing combinators, as in .error + {color: red}.

• Repeated combinators, as in div > > .error {color: red}.

None of these are valid CSS, and all of them will cause browsers to ignore the style rule in question. Supporting them added a substantial amount of complexity to Sass’s implementation, and made it particularly difficult to fix various bugs related to the @extend rule. As such, we made the decision to remove support for these uses.

There is one major exception: leading and trailing combinators may still be used for nesting purposes. For example, the following is still very much supported:

.sidebar > {
  .error {
    color: red;
  }
}

.sidebar >
  .error
    color: red

.sidebar > .error {
  color: red;
}

Sass will only produce an error if a selector still has a leading or trailing combinator after nesting is resolved. Repeated combinators, on the other hand, will always be errors.

To make sure existing stylesheets who (likely accidentally) contain invalid combinators, we’ll support a transition period until the next major release of Dart Sass.

Transition PeriodTransition Period permalink

Compatibility:

Dart Sass

since 1.54.0

LibSass

✗

Ruby Sass

✗

First, we’ll emit deprecation warnings for all double combinators, as well as leading or trailing combinators that end up in selectors after nesting is resolved.

In addition, we’ll immediately start omitting selectors that we know to be invalid CSS from the compiled CSS, with one exception: we won’t omit selectors that begin with a leading combinator, since they may be used from a nested @import rule or meta.load-css() mixin. However, we don’t encourage this pattern and will drop support for it in Dart Sass 2.0.0.

Can I Silence the Warnings?Can I Silence the Warnings? permalink

Sass provides a powerful suite of options for managing which deprecation warnings you see and when.

Terse and Verbose ModeTerse and Verbose Mode permalink

By default, Sass runs in terse mode, where it will only print each type of deprecation warning five times before it silences additional warnings. This helps ensure that users know when they need to be aware of an upcoming breaking change without creating an overwhelming amount of console noise.

If you run Sass in verbose mode instead, it will print every deprecation warning it encounters. This can be useful for tracking the remaining work to be done when fixing deprecations. You can enable verbose mode using the --verbose flag on the command line, or the verbose option in the JavaScript API.

Silencing Deprecations in DependenciesSilencing Deprecations in Dependencies permalink

Sometimes, your dependencies have deprecation warnings that you can’t do anything about. You can silence deprecation warnings from dependencies while still printing them for your app using the --quiet-deps flag on the command line, or the quietDeps option in the JavaScript API.

For the purposes of this flag, a "dependency" is any stylesheet that’s not just a series of relative loads from the entrypoint stylesheet. This means anything that comes from a load path, and most stylesheets loaded through custom importers.

Silencing Specific DeprecationsSilencing Specific Deprecations permalink

If you know that one particular deprecation isn’t a problem for you, you can silence warnings for that specific deprecation using the --silence-deprecation flag on the command line, or the silenceDeprecations option in the JavaScript API.