Sass und native Verschachtelung

Die stabile Version von Chrome 112, die heute veröffentlicht wird, ist der erste stabile Browser, der die Unterstützung für die neue native CSS-Verschachtelungsfunktion hinzufügt. Diese Funktion, die von der Sass-Verschachtelung inspiriert wurde, ermöglicht das Verschachteln von Stilregeln in reinem CSS und verwendet sogar die Sass-Konvention von &, um den übergeordneten Selektor zu referenzieren.

Wir hier bei Sass HQ fühlen uns jedes Mal geehrt, wenn unser Sprachdesign Verbesserungen in CSS selbst inspiriert. Wir freuen uns darauf, die Vorteile von Verschachtelungen in Bezug auf Benutzerfreundlichkeit und Klarheit für noch mehr CSS-Autoren zu sehen, da immer mehr Browser die Unterstützung für diese Funktion einführen.

Die Zukunft der Sass-VerschachtelungDie Zukunft der Sass-Verschachtelung Permalink

Dies wirft jedoch eine wichtige Frage auf: Was wird aus der Sass-Verschachtelung? Erstens werden wir niemals vorhandenen gültigen Sass-Code ändern, sodass er CSS erzeugt, das mit weit verbreiteten Browsern inkompatibel ist. Das bedeutet, selbst wenn wir uns entscheiden würden, die Sass-Verschachtelung auszulaufen und stattdessen nur die native CSS-Verschachtelung auszugeben, würden wir dies erst tun, wenn 98 % des globalen Browser-Marktanteils die native Verschachtelung unterstützen.

Wichtiger ist jedoch, dass die native CSS-Verschachtelung subtil inkompatibel mit der Sass-Verschachtelung ist. Dies betrifft drei verschiedene Fälle

1. Die native CSS-Verschachtelung umschließt den übergeordneten Selektor implizit in :is(), während Sass seinen Text in den aufgelösten Selektor kopiert. Das bedeutet , dass

   .foo, #bar {
     .baz { /* ... */ }
   }

   erzeugt den Selektor .foo .baz, #bar .baz in Sass, aber :is(.foo, #bar) .baz in nativem CSS. Dies ändert die Spezifität: :is() hat immer die Spezifität seines spezifischsten Selektors, daher wird :is(.foo, #bar) .baz

   <div class=foo>
     <p class=baz>
   </div>

   mit einer Spezifität von 1 0 1 in nativem CSS und 0 0 2 in Sass übereinstimmen, auch wenn keines der Elemente von IDs übereinstimmt.

2. Da die native CSS-Verschachtelung :is() verwendet, verhält sich ein übergeordneter Selektor mit Nachfolgern-Kombinatoren anders.

   .foo .bar {
     .green-theme & { /* ... */ }
   }

   erzeugt den Selektor .green-theme .foo .bar in Sass, aber in nativem CSS erzeugt er .green-theme :is(.foo .bar). Das bedeutet, dass die native CSS-Version übereinstimmen wird

   <div class=foo>
     <div class="green-theme">
       <p class=bar>
     </div>
   </div>

   aber Sass nicht, da das Element, das .foo entspricht, außerhalb des Elements liegt, das .green-theme entspricht.

3. Sass-Verschachtelung und native CSS-Verschachtelung unterstützen beide Syntax, die wie &foo aussieht, aber sie bedeuten unterschiedliche Dinge. In Sass wird ein Suffix zum übergeordneten Selektor hinzugefügt, sodass

   .foo {
     &-suffix { /* ... */ }
   }

   erzeugt den Selektor .foo-suffix. Aber in nativem CSS wird ein Typselektor zum übergeordneten Selektor hinzugefügt, sodass

   .foo {
     &div { /* ... */ }
   }

   erzeugt den Selektor div.foo (während Sass .foodiv erzeugen würde). Die native CSS-Verschachtelung hat keine Möglichkeit, ein Suffix zu einem Selektor wie Sass hinzuzufügen.

Design-VerpflichtungenDesign-Verpflichtungen Permalink

Bei der Betrachtung, wie mit dieser neuen CSS-Funktion umzugehen ist, haben wir zwei wichtige Design-Verpflichtungen zu beachten: 

• Wir sind bestrebt, eine CSS-Obermenge zu sein. Alle gültigen CSS-Regeln, die von einem echten Browser unterstützt werden, sollten auch in Sass mit denselben Semantik funktionieren.

• Wir sind bestrebt, Abwärtskompatibilität zu gewährleisten. Soweit möglich, möchten wir vermeiden, die Semantik bestehender Stylesheets zu ändern, und wenn wir dies tun müssen, möchten wir den Benutzern so viel Zeit und Ressourcen wie möglich geben, um die Änderung reibungslos vorzunehmen.

In den meisten Fällen hat die Beibehaltung einer CSS-Obermenge Vorrang vor der Abwärtskompatibilität. Verschachtelung ist jedoch eine der ältesten und am weitesten verbreiteten Sass-Funktionen, daher sind wir besonders widerwillig, sie zu ändern, insbesondere auf eine Weise, die die Unterstützung für weit verbreitete Funktionen wie &-suffix einstellen würde, für die es keine elegante Entsprechung in nativem CSS gibt.

Der Plan für SassDer Plan für Sass Permalink

Kurzfristig beabsichtigen wir nicht, etwas an der Sass-Verschachtelung zu ändern. Sass wird einfach keine reine CSS-Verschachtelung unterstützen, es sei denn, wir können dies auf eine Weise tun, die vollständig mit dem bestehenden Sass-Verhalten kompatibel ist.

Wir werden die Unterstützung für das Parsen von reinem CSS-Verschachtelung in .css-Dateien hinzufügen. Diese Verschachtelung wird in keiner Weise aufgelöst; Sass wird sie einfach so ausgeben, wie sie ist.

Langfristig werden wir, sobald :is() von 98 % des globalen Browser-Marktanteils unterstützt wird, beginnen, Sass so umzustellen, dass es :is() ausgibt, wenn Sass-Verschachtelung aufgelöst wird. Dies wird Sass im Hinblick auf die ersten beiden Verhaltensinkompatibilitäten wie CSS verhalten lassen. Wir werden dies als Breaking Change betrachten und ihn als Teil einer Hauptversionsfreigabe veröffentlichen, um unerwartete Unterbrechungen bestehender Stylesheets zu vermeiden. Wir werden unser Bestes tun, um diesen Übergang mit dem Sass Migrator so reibungslos wie möglich zu gestalten.

Wir werden unser aktuelles Verhalten für &-suffix nicht einstellen, es sei denn, wir können eine vergleichbar ergonomische Methode entwickeln, um es darzustellen, die mit CSS kompatibler ist. Dieses Verhalten ist für bestehende Sass-Benutzer zu wichtig, und der Nutzen der reinen CSS-Version ist nicht stark genug, um diesen zu überschreiben.