Sass 3.5 Release Candidate

Veröffentlicht am 30. August 2016 von Natalie Weizenbaum

Ich habe gerade den Knopf gedrückt, um Sass 3.5.0-rc.1 zu veröffentlichen. Wenn es sich so anfühlt, als wäre es eine Weile her seit der letzten Veröffentlichung, dann stimmt das! Aber es gibt einen guten Grund dafür. Wir haben beschlossen, nach der Veröffentlichung von 3.5 in den Feature Freeze zu gehen, um libsass, die super-schnelle C++-Implementierung von Sass, Zeit zu geben, die Feature-Parität mit Sass 3.4 zu erreichen. Libsass ist viel jünger als Sass, und C++ ist im Allgemeinen eine langsamere Sprache als Ruby, daher hat dies einige Zeit gedauert. Aber es hat sich ausgezahlt: libsass ist jetzt fast 100% kompatibel mit Ruby Sass und unterscheidet sich nur in wenigen kleinen Fehlern.

Nachdem der Feature Freeze aufgehoben wurde, konzentrierten wir uns hauptsächlich auf das Design des neuen Modulsystems, das das zentrale Merkmal von Sass 4.0 sein wird. Aber wir fanden auch etwas Zeit, um einige neue Funktionen hinzuzufügen, die der Schwerpunkt dieser Veröffentlichung sind.

CSS Custom Property SupportCSS Custom Property Support  Permalink

Sass 3.5 unterstützt jetzt vollständig CSS Custom Properties. Diese stellten für uns eine besondere Herausforderung dar, da die Syntax für Custom Properties *extrem* breit gefächert ist. Sie können fast alles auf der rechten Seite einfügen. Zum Beispiel ist dies völlig gültiges, aussagekräftiges CSS

.wacky-property {
  --property: .%(#@$~`^[^_+]<;:"}"|?)*+;
}

Insbesondere bedeutet dies, dass SassScript-Ausdrücke *auch* gültiges CSS sind, was ein Problem für unser Ziel der CSS-Kompatibilität darstellt. Wo immer möglich, möchten wir, dass gültiges CSS in Sass dasselbe bedeutet wie in CSS. Custom Properties also einfach wie normale Properties zu behandeln – was wir in 3.4 getan haben – war keine gute Lösung. Nicht nur, dass einige gültige CSS-Teile anders interpretiert wurden, einige waren nicht einmal möglich. Das folgende CSS, direkt aus der Polymer-Dokumentation, war in Sass kaum darstellbar.

:host {
  --my-toolbar-theme: {
    background-color: green;
    border-radius: 4px;
    border: 1px solid gray;
  }
}

Andererseits benötigten wir *irgendeine* Möglichkeit, dynamische SassScript-Werte in Custom Properties einzufügen. Also entschieden wir uns für einen Kompromiss: Wir behandeln Custom Properties wie Selektoren und At-Rule-Werte und erlauben nur #{} als Mittel zur Einbindung von Sass-Werten. Obwohl dies technisch gesehen reines CSS ist, ist es eine sehr kleine Fläche und sehr leicht zu escapen, daher sind wir nicht zu besorgt. Das bedeutet, dass Sie in 3.5 schreiben können

:host {
  --my-toolbar-theme: {
    background-color: #{$toolbar-background};
    border-radius: 4px;
    border: 1px solid gray;
  }
}

Neuer Datentyp: First-Class FunctionsNeuer Datentyp: First-Class Functions  Permalink

In Vorbereitung auf das Modulsystem, das in Sass 4.0 kommt, fügt 3.5 einen neuen Datentyp hinzu: First-Class Functions. Dies ist nur eine Möglichkeit, auf eine Funktion zu verweisen, die spezifischer ist als nur ihr Name. Sie können eine First-Class Function erhalten, indem Sie ihren Namen an get-function($name) übergeben, und Sie können sie an call() übergeben, wo Sie früher den Funktions namen übergeben haben.

Sie fragen sich vielleicht: "Warum ist das nützlich? Ich konnte den Funktionsnamen bereits übergeben." Nun, im Moment hat Sass einen globalen Scope. Alle Funktionen (sowie Variablen, Mixins und Selektoren) sind für jeden Code sichtbar, der später ausgeführt wird. Das macht einige Dinge wie call() einfach, verursacht aber auch viele Probleme. Es ist viel zu einfach, versehentlich eine Variable oder Funktion zu überschreiben, die woanders definiert wurde, und es ist viel zu schwierig herauszufinden, wo ein bestimmter Name ursprünglich definiert wurde.

Wir sind noch nicht bereit, ausführlich über unsere Pläne für das 4.0-Modulsystem zu sprechen, aber eines der Dinge, bei denen wir uns sicher sind, ist, dass es keinen globalen Scope verwenden wird. Jede Sass-Datei kann nur eine begrenzte Anzahl der definierten Namen sehen, und Sass-Bibliotheken können insbesondere nichts sehen, das von den Endbenutzer-Stylesheets definiert wurde, die sie importieren. First-Class Functions ermöglichen es Benutzern, definierte Funktionen an Bibliotheken zu übergeben.

Alle Stylesheets, die derzeit Funktionsnamen als Strings übergeben, sollten dazu übergehen, stattdessen First-Class Functions zu übergeben. Zu diesem Zweck wurde das Aufrufen von call() mit einem String als veraltet markiert. Es wird bis 4.0 nicht wirklich brechen, wo es sowieso nicht mehr viel Sinn machen wird, aber wir ermutigen Benutzer dringend, sofort zu get-function() zu wechseln.

Neue Syntax: Bracketed ListsNeue Syntax: Bracketed Lists  Permalink

Das neue CSS Grid Layout Modul hat eine neue Art von Syntax hinzugefügt: Bezeichner, die von eckigen Klammern umschlossen sind. Wir streben immer danach, mit CSS vollständig kompatibel zu sein, was bedeutete, dass wir auch diese Klammern unterstützen mussten. Hier sehen sie in CSS aus.

.container {
  grid-template-columns: [first] 40px [line2] 50px [line3] auto [col4-start] 50px [five] 40px [end];
  grid-template-rows: [row1-start] 25% [row1-end] 100px [third-line] auto [last-line];
}

Die Lösung war klar: Sass hat bereits einen Listen-Datentyp, daher erlauben wir einfach Listen, eckige Klammern zu haben. Also ist [first] nur eine Liste, die den unquoted String first enthält. Wie alle Sass-Listen können auch Bracketed Lists entweder durch Leerzeichen oder durch Kommas getrennt sein: [foo bar baz] und [foo, bar, baz] sind beide Listen mit drei Elementen.

Wir haben auch Funktionsunterstützung für Bracketed Lists hinzugefügt. Die Funktion is-bracketed($list) gibt zurück, ob eine Liste als "bracketed" gilt oder nicht, und join() hat einen neuen Parameter $bracketed, der es dem Aufrufer ermöglicht zu wählen, ob die resultierende Liste Klammern haben soll (standardmäßig ist das Ergebnis "bracketed", wenn die erste Liste es ist).

Kleinere FeaturesKleinere Features permalink

Wir haben eine Funktion content-exists() hinzugefügt, die zurückgibt, ob ein Content-Block an den aktuellen Mixin übergeben wurde oder nicht. Dies ermöglicht es Mixins, optional einen Content-Block zu akzeptieren, anstatt einen Mixin definieren zu müssen, der Content annimmt, und einen, der es nicht tut.

Wir haben die Möglichkeit hinzugefügt, Argumentlisten mit einem nachgestellten Komma zu versehen. Dies entspricht dem Verhalten von Listen und Maps.

Wir haben einen Parameter $weight zur Funktion invert() hinzugefügt. Dies ist ein Prozentsatz zwischen 0% und 100%, der angibt, wie invertiert die resultierende Farbe sein soll. Er hat einen Standardwert von 100%.

Der Weg zur VeröffentlichungDer Weg zur Veröffentlichung  Permalink

Dies ist nur ein Release Candidate, aber er ist an einem Punkt, an dem wir ihn gerne als finale Version ausliefern würden. Wir tun dies nicht, weil wir, nachdem wir die Feature-Kompatibilität mit libsass erreicht haben, uns verpflichtet fühlen, dort zu bleiben.

Leider bewegt sich libsass in letzter Zeit ziemlich langsam, seit Marcel Greter das Projekt verlassen hat. Wenn Sie oder jemand, den Sie kennen, daran interessiert wären, an einem Projekt zu arbeiten, das Tausenden von Menschen zugutekommt, suchen wir immer noch nach neuen Mitarbeitern!

Bis wir libsass-Kompatibilität haben, wird 3.5 auf dem Niveau eines Release Candidates bleiben. Aber lassen Sie sich davon nicht davon abhalten, es auszuprobieren und uns Ihre Meinung mitzuteilen! Wir sind immer daran interessiert, Feedback auf der Mailingliste zu erhalten!