Breaking Change: Color JS API
Bestimmte Aspekte der JS-Farb-API, die mit der Annahme entwickelt wurden, dass alle Farben gegenseitig kompatibel sind, ergeben nun keinen Sinn mehr, da Sass alle Farbräume von CSS Color 4 unterstützt.
So wie einige Aspekte der Farbfunktionen von Sass mit der Unterstützung für CSS Color 4 veraltet sind, sind auch einige Ecken der JS-API für die Manipulation von Farben veraltet.
color.change() erfordert nun einen space für die domänenübergreifende Änderungcolor.change() erfordert nun einen Space für domänenübergreifende Änderungen Permalink
Zuvor nahm die Methode color.change() nur eine Reihe von Kanalnamen aus den RGB-, HSL- oder HWB-Räumen entgegen. Solange diese Kanäle nicht über Räume hinweg gemischt wurden (z. B. durch gleichzeitige Änderung von red und hue), konnte Sass ermitteln, welcher Raum gemeint war.
Mit Color 4 sind Farbräume allein anhand ihrer Kanalnamen nicht mehr eindeutig. Viele Räume haben red-, green- und blue-Kanäle mit unterschiedlichen Bereichen; viele Räume haben hue-Kanäle, die sehr unterschiedliche Farbkreise erzeugen. Um diese Mehrdeutigkeit zu beheben, nimmt color.change() nun einen space-Parameter entgegen, der explizit den Namen des Farbraums angibt, in dem die Transformation erfolgen soll.
const color = new sass.SassColor({red: 0x66, green: 0x33, blue: 0x99});
color.change({hue: 270, space: "okclh"});
Die Angabe des Farbraums ist obligatorisch, wenn die betreffende Farbe sich nicht in einem Legacy-Farbraum befindet oder wenn Sie einen Kanal wie Chroma ändern, der nur in Nicht-Legacy-Farbräumen existiert. Er ist immer optional, wenn Sie einen Kanal ändern, der im eigenen Raum der Farbe existiert, so dass color.change({red: 0.8}) immer auf den nativen roten Kanal jeder Farbe mit red-, green- und blue-Kanälen verweist.
Aus Kompatibilitätsgründen wird Sass die Farbe immer noch automatisch konvertieren, wenn Sie Legacy-Kanäle für eine Legacy-Farbe ändern. Dieses Verhalten ist jedoch veraltet. Um auf Nummer sicher zu gehen, sollten Sie **immer** den space-Parameter übergeben, es sei denn, Sie sind sicher, dass die Farbe bereits im Farbraum ist, dessen Kanal Sie ändern möchten möchten.
null-Kanalwertenull-Kanalwerte Permalink
Eine der wichtigsten Änderungen in CSS Color 4 ist das neue Konzept der "fehlenden" Kanäle. Zum Beispiel hat hsl(none 0% 40%) einen fehlenden Farbton, der in den meisten Fällen als 0 behandelt wird, aber nicht zur Farbinterpolation beiträgt, so dass ein Gradient mit dieser Farbe in der Mitte keinen phantomroten Farbton hat. Beim Erstellen von Farben stellt Sass fehlende Werte als den Wert null dar.
Vor der Unterstützung von CSS Color 4 verboten die TypeScript-Typen der Sass JS-API die Verwendung von null an allen relevanten Stellen. Der Code selbst behandelte null jedoch wie undefined, und wir möchten die Kompatibilität mit reinem JavaScript-Code, der sich auf dieses Verhalten verlässt, nicht brechen. Vorerst wird ein null-Wert als undefined behandelt und gibt eine Verwarnung aus, wenn eine neue [Legacy-Farbe] erstellt oder color.change() für eine Legacy-Farbe aufgerufen wird. In beiden Fällen, wenn Sie einen space-Parameter explizit übergeben, entscheiden Sie sich für das neue Verhalten und null wird als fehlender Kanal behandelt.
ÜbergangszeitraumÜbergangszeitraum Permalink
- Dart Sass
- seit 1.79.0
- LibSass
- ✗
- Ruby Sass
- ✗
Zuerst geben wir Verwarnungen für alle Verwendungen dieser APIs aus, die geändert werden sollen. In Dart Sass 2.0.0 treten die Breaking Changes vollständig in Kraft, und das alte Verhalten wird nicht mehr wie bisher funktionieren wie bisher.
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 Sass im ausführlichen Modus ausführen, werden *alle* aufgetretenen Verwarnungen ausgegeben. Dies kann hilfreich sein, um die verbleibenden Arbeiten bei der Behebung von Verwarnungen zu verfolgen. Sie können den ausführlichen Modus mit 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 Verwarnungen, gegen die Sie nichts tun können. Sie können Verwarnungen von Abhängigkeiten unterdrücken und gleichzeitig die Warnungen für Ihre App ausgeben, indem Sie 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 Verwarnung für Sie kein Problem darstellt, können Sie Warnungen für diese spezielle Verwarnung mit der Option silenceDeprecations in der JavaScript-API unterdrücken.