Eine Planänderung für Sass 3.3

Dies wurde ursprünglich als ein Gist veröffentlicht.

Sass 3.3 kommt bald und mit ihm mehrere wichtige neue Funktionen. Es unterstützt Source Maps, SassScript Maps und die Verwendung von & in SassScript. Zur Vorbereitung der Veröffentlichung haben wir einige Release Candidates herausgebracht, um sicherzustellen, dass alles bereit ist. Leider war dies nicht der Fall.

Release Candidates decken oft kleine Fehler und Inkonsistenzen in neuen Funktionen auf, aber selten etwas wirklich Verheerendes. In diesem Fall bemerkten jedoch mehrere Benutzer ein Problem bei der Verwendung von & in SassScript, das einen erheblichen Teil unseres Plans für diesen Abschnitt von 3.3 unbrauchbar machte. Es ist kein fataler Fehler und wir denken, wir haben einen guten Plan, damit umzugehen (dazu komme ich gleich), aber es ist ein Problem.

Der HintergrundPermanenter Link zum Hintergrund

Um zu verstehen, was falsch ist, müssen Sie zuerst den Grund verstehen, warum wir uns überhaupt entschieden haben, & für SassScript zugänglich zu machen. Eine Sache, die Benutzer ziemlich oft tun möchten, ist, Klassen Suffixe hinzuzufügen. Manchmal ersetzt dies die Verschachtelung von Selektoren, manchmal dient es einfach dazu, eine neue Klasse basierend auf den alten zu erstellen – der Grund spielt für diese Diskussion keine große Rolle. Wenn Leute versuchten, dies zu tun, schrieben sie etwas wie .foo { &-suffix { ... } }, und es funktionierte nicht. Der Grund ist, dass & dieselbe syntaktische Funktion wie ein Typselektor (z. B. h1) oder ein Universalselektor (*) hat, da es durch einen dieser ersetzt werden könnte. Es ergibt keinen Sinn, *-suffix in einem Selektor zu schreiben, daher war &-suffix auch nicht erlaubt.

Dies hielt die Leute jedoch nicht davon ab, es tun zu wollen. Also entschieden wir uns: "In Ordnung, wir verwenden bereits Interpolation (#{}), um das Einfügen von Text in Selektoren zu unterstützen – verwenden wir einfach das." Wir beschlossen, & als eine Art spezielle Variable in SassScript hinzuzufügen, die eine geparste Darstellung des aktuellen Selektors enthielt. Sie konnten dann &-suffix nachahmen, indem Sie stattdessen @at-root #{&}-suffix^[1] verwenden. Das Leben war schön, bis unsere unerschrockenen Benutzer das Problem entdeckten.

Das ProblemPermanenter Link zum Problem

Hier ist ein kleiner Auszug ausSCSS, der das Problem demonstriert. Versuchen Sie herauszufinden es

.foo, .bar {
  @at-root #{&}-suffix {
    color: blue;
  }
}

Haben Sie es verstanden? Genau: & ist in diesem Beispiel .foo, .bar, was bedeutet, dass der Selektor zu .foo, .bar-suffix kompiliert wird. Da #{} reinen alten Text einfügt, gibt es keine Möglichkeit für Sass, herauszufinden, wie es den Selektor aufteilen soll.

Chris und ich haben lange und viel darüber gesprochen, wie wir das beheben können. Wir haben die Hinzufügung einer Funktion zum Hinzufügen des Suffixes in Erwägung gezogen, aber das war zu umständlich. Wir haben erwogen, & so zu gestalten, dass es die Kompilierung der CSS-Regel in mehrere parallele Regeln aufteilt, von denen jede einen einzelnen Selektor für & hatte, aber das war zu kompliziert und versagte in zu vielen Randfällen. Wir kamen schließlich zu dem Schluss, dass es keine Möglichkeit gab, SassScript &, um den Anwendungsfall, für den wir es entworfen hatten, sauber zu unterstützen 

Die LösungPermanenter Link zur Lösung

Wir wussten, dass wir den &-suffix-Anwendungsfall unterstützen wollten, und unser cleverer Plan dafür war gescheitert. Wir steckten unsere Köpfe zusammen und diskutierten und entschieden, dass der beste Weg, ihn zu unterstützen, der einfachste war: Wir würden &-suffix einfach zulassen. Dies war schließlich das, was die meisten Leute zuerst versuchten, wenn sie dieses Verhalten wollten, und mit dem & direkt im Selektor eingebettet, können wir Selektorlisten leicht handhaben.

Das bedeutet, dass &-suffix in Sass 3.3 unterstützt wird, ohne #{} oder @at-root zu benötigen. Ich habe Issue 1055 erstellt, um es zu verfolgen. Beim Kompilieren dieser Selektoren, wenn der übergeordnete Selektor ein solcher ist, der zu einem ungültigen Selektor führen würde (z. B. *-suffix oder :nth-child(1)-suffix), werden wir dort einen Fehler auslösen, der erklärt, warum dieser Selektor generiert wurde.

Wir sind immer noch besorgt über Fälle, in denen Leute Mixins mit &-suffix schreiben, die dann mit bestimmten übergeordneten Selektoren nicht funktionieren. In diesem Fall haben wir jedoch festgestellt, dass dies das geringste Übel von allen verfügbaren wäre.

Die Zukunft von & in SassScriptDie Zukunft von & in SassScript Permalink

Zusätzlich zur Unterstützung von &-suffix haben wir beschlossen, SassScript & aus der 3.3-Veröffentlichung zu entfernen. Seien Sie versichert, dass es zurückkehren wird – wir erkennen an, dass es andere gute Anwendungsfälle gibt und beabsichtigen, es für die nächste große Veröffentlichung (wahrscheinlich 3.4) wieder einzuführen. Zusätzlich wird es mit einer Reihe von Funktionen zur Manipulation der von ihm bereitgestellten Selektoren geliefert, so dass es leistungsfähiger als jemals sein wird.

Es gibt zwei Gründe, warum wir die Verwendung von & in SassScript vorerst zurückhalten wollen. Der erste Grund ist, dass wir Zeit brauchen, um die Funktionen zu erstellen, die damit einhergehen, und sie auf Herz und Nieren zu prüfen. Dies kann Änderungen an der Funktionsweise auf verschiedene Weise erfordern, und wir möchten keine abwärtskompatiblen Änderungen vornehmen müssen.

Der zweite Grund ist, dass wir viel Energie darauf verwendet haben, #{&} als Lösung für das &-suffix-Problem anzupreisen. Das ist eindeutig unsere eigene Schuld, aber es ist wahr und es ist etwas, womit wir uns befassen müssen. Dass &-suffix funktioniert, ist großartig, aber wenn alle #{&} sowieso verwenden, weil wir ihnen vor ein paar Monaten davon erzählt haben, dann tut es nicht alles, was es kann. Eine Veröffentlichung zu haben, in der &-suffix funktioniert, aber #{&} nicht, wird den Benutzern helfen, den besten Weg zur Lösung ihres Problems zu finden, bevor wir die fortschrittlichere Funktionalität verfügbar machen.

@at-root wird weiterhin in Sass 3.3 enthalten sein.

Veröffentlichung von 3.3Permanenter Link zur Veröffentlichung von 3.3

Leider wird diese Änderung die Veröffentlichung von 3.3 verzögern, hoffentlich aber nicht allzu sehr. Ich gehe davon aus, dass dies relativ einfach zu implementieren sein wird; die größte Hürde war herauszufinden, was zu tun ist, und dieser Teil ist erledigt. Ich plane, nach meiner Rückkehr aus dem Winterurlaub viel Zeit darauf zu verwenden, 3.3 auf den Markt zu bringen, also wird es hoffentlich (keine Versprechungen) irgendwann im Januar veröffentlicht.

---

1. Das @at-root ist notwendig, da Sass nicht zuverlässig ermitteln kann, ob & im Selektor verwendet wurde, so wie es dies kann, wenn & ohne #{} verwendet wird. ↩︎