Breaking Change: Strikte Funktions-Einheiten

Verschiedene integrierte Funktionen werden strikter darin, welche Einheiten sie zulassen, und werden diese Einheiten konsistenter behandeln. Dies macht Sass kompatibler mit der CSS-Spezifikation und hilft, Fehler schneller zu erkennen.

Farbton

Dart Sass: seit 1.32.0
LibSass: ✗
Ruby Sass: ✗

Bei der Angabe des Farbtons einer Farbe erlaubt CSS jede Winkel-Einheit (deg, grad, rad oder turn). Es erlaubt auch eine zahl ohne Einheit, die als deg interpretiert wird. Historisch gesehen hat Sass *jede* Einheit zugelassen und sie als deg interpretiert. Dies ist besonders problematisch, da es bedeutete, dass der gültige CSS-Ausdruck hsl(0.5turn, 100%, 50%) von Sass zugelassen, aber völlig falsch interpretiert würde.

Um dieses Problem zu beheben und Sass mit der CSS-Spezifikation in Einklang zu bringen, nehmen wir in mehreren Phasen Änderungen vor.

Phase 1

Dart Sass: seit 1.32.0
LibSass: ✗
Ruby Sass: ✗

Zuerst hat Sass nur eine Warnung ausgegeben, wenn Sie eine Zahl mit einer anderen Einheit als deg als Farbton an eine Funktion übergeben haben. Die Übergabe einer zahl ohne Einheit ist weiterhin zulässig.

Phase 2

Dart Sass: seit 1.52.1
LibSass: ✗
Ruby Sass: ✗

Als nächstes haben wir die Art und Weise geändert, wie Winkeleinheiten für Farbtonparameter behandelt werden, um der CSS-Spezifikation zu entsprechen. Das bedeutet, dass Zahlen mit grad-, rad- oder turn-Einheiten in deg umgewandelt werden: 0.5turn wird in 180deg umgewandelt, 100grad in 90deg und so weiter.

Da diese Änderung zur Wahrung der CSS-Kompatibilität notwendig ist, wurde sie gemäß der Kompatibilitätsrichtlinie von Dart Sass nur mit einem Minor-Versions-Bump vorgenommen. Sie ändert jedoch das Verhalten so wenig wie möglich, um sicherzustellen, dass Sass alle gültigen CSS-Angaben gemäß der CSS-Spezifikation interpretiert.

Phase 3

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

Schließlich werden in Dart Sass 2.0.0 Farb-Funktionen Fehler auslösen, wenn ihnen ein Farbton-Parameter mit einer Nicht-Winkel-Einheit übergeben wird. Farbwerte ohne Einheit sind weiterhin zulässig.

Sättigung und Helligkeit

Bei der Angabe der Sättigung und Helligkeit einer HSL-Farbe erlaubt CSS nur %-Einheiten. Selbst Zahlen ohne Einheit sind nicht zulässig (im Gegensatz zum Farbton). Historisch hat Sass *jede* Einheit zugelassen und sie als % interpretiert. Sie könnten sogar hsl(0, 100px, 50s) schreiben und Sass würde die Farbe red zurückgeben.

Um dieses Problem zu beheben und Sass mit der CSS-Spezifikation in Einklang zu bringen, nehmen wir in zwei Phasen Änderungen vor.

Phase 1

Dart Sass: seit 1.32.0
LibSass: ✗
Ruby Sass: ✗

Derzeit gibt Sass nur eine Warnung aus, wenn Sie eine Zahl ohne Einheit oder mit einer anderen Einheit als % als Helligkeit oder Sättigung an eine Funktion übergeben.

Phase 2

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

In Dart Sass 2.0.0 werden Farb-Funktionen Fehler auslösen, wenn ihnen ein Sättigungs- oder Helligkeits-Parameter ohne Einheit oder mit einer Nicht-%-Einheit übergeben wird.

Alpha

Bei der Angabe des Alpha-Werts einer Farbe erlaubt CSS (ab Colors Level 4) entweder Werte ohne Einheit zwischen 0 und 1 oder %-Werte zwischen 0% und 100%. In den meisten Fällen folgt Sass diesem Verhalten, aber die Funktionen color.adjust() und color.change() haben historisch *jede* Einheit zugelassen und sie als ohne Einheit interpretiert. Sie könnten sogar color.change(red, $alpha: 1%) schreiben und Sass würde die opake Farbe red zurückgeben.

Um dieses Problem zu beheben und Sass mit der CSS-Spezifikation in Einklang zu bringen, nehmen wir in drei Phasen Änderungen vor.

Phase 1

Dart Sass: seit 1.56.0
LibSass: ✗
Ruby Sass: ✗

Derzeit gibt Sass nur eine Warnung aus, wenn Sie eine Zahl mit einer beliebigen Einheit, einschließlich %, als Alpha-Wert an color.change() oder color.adjust() übergeben.

Phase 2

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

Als nächstes ändern wir die Art und Weise, wie %-Einheiten für das Alpha-Argument von color.change() und color.adjust() behandelt werden. Alphas mit der Einheit % werden durch 100% geteilt und in werte ohne Einheit zwischen 0 und 1 umgewandelt.

Da diese Änderung eine Fehlerbehebung ist, die die Konsistenz mit anderen Sass-Funktionen verbessert, wird sie nur mit einem Minor-Versions-Bump vorgenommen. Sie wird mindestens drei Monate nach der Veröffentlichung von Phase 1 geändert, um den Benutzern Zeit zu geben, ihren Code anzupassen und den Fehler zu vermeiden.

Phase 3

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

Schließlich werden in Dart Sass 2.0.0 color.change() und color.adjust() Fehler auslösen, wenn ihnen ein Alpha-Parameter mit einer Nicht-%-Einheit übergeben wird. Werte ohne Einheit sind weiterhin zulässig.

`math.random()`

Die Funktion math.random() hat historisch Einheiten im $limit-Argument ignoriert und einen wert ohne Einheit zurückgegeben. Zum Beispiel würde math.random(100px) "px" fallen lassen und einen Wert wie 42 zurückgeben.

Eine zukünftige Version von Sass wird aufhören, Einheiten für das $limit-Argument zu ignorieren, und eine zufällige Ganzzahl mit denselben Einheiten zurückgeben.

  SCSS

  Sass

       SpielplatzSCSS-Syntax@use "sass:math";

// Future Sass, doesn't work yet!
@debug math.random(100px); // 42px

       SpielplatzSass-Syntax@use "sass:math"

// Future Sass, doesn't work yet!
@debug math.random(100px)  // 42px

Phase 1

Dart Sass: seit 1.54.5
LibSass: ✗
Ruby Sass: ✗

Derzeit gibt Sass eine Warnung aus, wenn Sie eine $limit mit Einheiten an math.random() übergeben.

Phase 2

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

In Dart Sass 2.0.0 wird die Übergabe einer $limit-Zahl mit Einheiten zu einem Fehler.

Phase 3

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

In einem Minor-Release nach Dart Sass 2.0.0 wird die Übergabe einer $limit-Zahl mit Einheiten an die Funktion math.random() wieder zulässig sein. Sie gibt eine zufällige Ganzzahl mit denselben Einheiten wie $limit zurück, anstatt eines wert ohne Einheit.

Gewichtung

Die Funktionen color.mix() und color.invert() haben beide historisch Einheiten in ihren $weight-Argumenten ignoriert, obwohl dieses Argument konzeptionell ein Prozentwert ist. Eine zukünftige Version von Sass wird die Einheit % verlangen.

Phase 1

Dart Sass: seit 1.56.0
LibSass: ✗
Ruby Sass: ✗

Derzeit gibt Sass eine Warnung aus, wenn Sie eine $weight ohne Einheit oder mit einer anderen Einheit als % an color.mix() oder color.invert() übergeben.

Phase 2

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

In Dart Sass 2.0.0 werden color.mix() und color.invert() Fehler auslösen, wenn ihnen eine $weight ohne Einheit oder mit einer Nicht-%-Einheit übergeben wird.

Index

Die Funktionen list.nth() und list.set-nth() haben beide historisch Einheiten in ihren $n-Argumenten ignoriert. Eine zukünftige Version von Sass wird alle Einheiten verbieten.

Phase 1

Dart Sass: seit 1.56.0
LibSass: ✗
Ruby Sass: ✗

Derzeit gibt Sass eine Warnung aus, wenn Sie eine $weight ohne Einheit oder mit einer anderen Einheit als % an color.mix() oder color.invert() übergeben.

Phase 2

Dart Sass: ✗
LibSass: ✗
Ruby Sass: ✗

In Dart Sass 2.0.0 werden list.nth() und list.set-nth() Fehler auslösen, wenn ihnen ein Index $n mit einer Einheit übergeben wird.

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.