Breaking Change: -moz-document

Firefox hatte früher eine @-moz-document-Regel, die eine spezielle Analyse erforderte. Da die Unterstützung in Firefox entfernt wird, entfernt Sass die Unterstützung für die Analyse davon.

Sass unterstützte historisch eine spezielle Analyse für die Regel @-moz-document. Da Firefox die Unterstützung dafür eingestellt hat, wird Sass ebenfalls die Unterstützung für die spezielle Analyse einstellen und sie als unbekannte at-rule behandeln.

Es gibt eine Ausnahme: Eine leere URL-Präfixfunktion ist immer noch erlaubt, da diese in einem Hack verwendet wird, der auf Firefox abzielt.

Spielplatz

SCSS-Syntax

@-moz-document url-prefix() {
  .error {
    color: red;
  }
}
Spielplatz

Sass-Syntax

@-moz-document url-prefix()
  .error
    color: red

CSS-Ausgabe

@-moz-document url-prefix() {
  .error {
    color: red;
  }
}

ÜbergangszeitraumÜbergangszeitraum Permalink

Kompatibilität
Dart Sass
seit 1.7.2
LibSass
✗
Ruby Sass
✗

Zuerst werden wir Warnungen vor der Veralterung für alle Verwendungen von @-moz-document ausgeben, mit Ausnahme des leeren url-prefix hacks.

In Dart Sass 2.0 wird @-moz-document als unbekannte at-rule behandelt.

Kann ich die Warnungen unterdrücken?

Sass bietet eine leistungsstarke Reihe von Optionen zur Verwaltung, welche Deprecations-Warnungen Sie wann sehen.

Terse- und Verbose-Modus

Standardmäßig läuft Sass im Terse-Modus, in dem jede Art von Deprecations-Warnung nur fünfmal ausgegeben wird, bevor weitere Warnungen unterdrückt werden. Dies stellt sicher, dass die Benutzer wissen, wann sie sich einer bevorstehenden Breaking Change bewusst sein müssen, ohne eine überwältigende Menge an Konsolenrauschen zu erzeugen.

Wenn Sie stattdessen Sass im Verbose-Modus ausführen, wird jede Deprecations-Warnung ausgegeben. Dies kann nützlich sein, um die verbleibende Arbeit bei der Behebung von Deprecations zu verfolgen. Sie können den Verbose-Modus mit dem Flag --verbose in der Befehlszeile oder der Option verbose in der JavaScript API aktivieren.

⚠️ Vorsicht!

Wenn Sass über die JS API ausgeführt wird, teilt Sass keine Informationen über Kompilierungen hinweg. Daher werden standardmäßig fünf Warnungen für *jedes kompilierte Stylesheet* ausgegeben. Sie können dies jedoch beheben, indem Sie einen benutzerdefinierten Logger schreiben (oder den Autor Ihres bevorzugten Frameworks dazu auffordern, dies zu tun), der nur fünf Fehler pro Deprecation ausgibt und über mehrere Kompilierungen hinweg geteilt werden kann.

Deprecations in Abhängigkeiten unterdrücken

Manchmal haben Ihre Abhängigkeiten Deprecations-Warnungen, auf die Sie keinen Einfluss haben. Sie können Deprecations-Warnungen von Abhängigkeiten unterdrücken, während sie für Ihre Anwendung weiterhin ausgegeben werden, indem Sie das Flag --quiet-deps in der Befehlszeile oder die Option quietDeps in der JavaScript API verwenden.

Für die Zwecke dieses Flags ist eine "Abhängigkeit" jedes Stylesheet, das keine reine Serie relativer Ladevorgänge vom Einstiegs-Stylesheet ist. Das bedeutet alles, was von einem Lade-Pfad kommt, und die meisten Stylesheets, die über benutzerdefinierte Importer geladen werden.

Spezifische Deprecations unterdrücken

Wenn Sie wissen, dass eine bestimmte Deprecation für Sie kein Problem darstellt, können Sie Warnungen für diese spezifische Deprecation unterdrücken, indem Sie das Flag --silence-deprecation in der Befehlszeile oder die Option silenceDeprecations in der JavaScript API verwenden.