Sass Style Guide

Da immer mehr Leute in Sass schreiben, lohnt es sich, darüber nachzudenken, wie wir es formatieren. CSS-Style-Guides sind üblich, also können wir diese vielleicht erweitern, um spezifische Sass-Entscheidungen abzudecken.

Hier sind einige Ideen, zu denen ich tendiere. Vielleicht sind sie nützlich für Sie oder helfen Ihnen, eigene Ideen zu entwickeln. Wenn Sie weitere Beispiele suchen, ist Sass Guidelines eine weitere gute Anlaufstelle.

Verwenden Sie Ihre regulären CSS-Formatierungsregeln / Style Guide

In diesem Beitrag geht es um Sass-spezifische Dinge, aber als Grundlage sollten Sie alle guten CSS-Formatierungsrichtlinien befolgen, die Sie bereits einhalten. Wenn Sie dies noch nicht tun, kann Ihnen diese Zusammenfassung von Style Guides helfen. Dazu gehören Dinge wie:

1. Seien Sie konsistent bei der Einrückung
2. Seien Sie konsistent, wo Leerzeichen vor/nach Doppelpunkten/Klammern platziert werden
3. Ein Selektor pro Zeile, Eine Regel pro Zeile
4. Listen Sie verwandte Eigenschaften zusammen auf
5. Haben Sie einen Plan für die Benennung von Klassennamen
6. Verwenden Sie keine IDs #hotdrama
7. usw.

List @extend(s) zuerst

.weather {
  @extend %module; 
  ...
}

Sofort zu wissen, dass diese Klasse von anderen Regeln erbt, ist gut. Ein weiterer Vorteil ist, dass das Überschreiben von Stilen für diesen geerbten Satz von Regeln dadurch viel einfacher wird.

Zu wissen, wann @extend anstelle von @include verwendet werden soll, kann etwas knifflig sein. Harry macht eine gute Arbeit, die beiden zu unterscheiden und bietet Gedanken, wie man beide verwendet.

List @include(s) next

.weather {
  @extend %module; 
  @include transition(all 0.3s ease-out);
  ...
}

Als Nächstes kommen Ihre @includes für Mixins und andere Funktionen. Auch dies ist gut, um es für die Referenz ganz oben zu haben, aber es ermöglicht auch Überschreibungen. Sie könnten sich auch entscheiden, benutzerdefinierte @includes von vendor-seitigen @includes zu trennen.

Listen Sie "reguläre" Stile als Nächstes auf

.weather {
  @extend %module;
  @include transition(all 0.3s ease-out);
  background: LightCyan;
  ...
}

Das Hinzufügen unserer regulären Stile nach den @Extends und @Includes ermöglicht es uns, diese Eigenschaften bei Bedarf richtig zu überschreiben.

Verschachtelte Pseudo-Klassen und Pseudo-Elemente als Nächstes

.weather {
  @extend %module;
  @include transition(all 0.3s ease-out);
  background: LightCyan;
  &:hover {
    background: DarkCyan;
  }
  &::before {
    content: "";
    display: block;
  }
  ...
}

Pseudo-Elemente und Pseudo-Klassen beziehen sich direkt auf das Element selbst, daher verschachteln wir sie aus diesem Grund zuerst vor anderen Selektoren. Dass Pseudo-Elemente vor Klassen kommen, scheint etwas einfacher zu lesen zu sein, aber ob das eine vor dem anderen kommt, ist reine Geschmackssache. So oder so ist es vielleicht am besten, Elemente mit anderen Elementen und Klassen mit anderen Klassen zusammenzuhalten.

Verschachtelte Selektoren zuletzt

.weather {
  @extend %module; 
  @include transition(all 0.3s ease);
  background: LightCyan;
  &:hover {
    background: DarkCyan;
  }
  &::before {
    content: "";
    display: block;
  }
  > h3 {
    @include transform(rotate(90deg));
    border-bottom: 1px solid white;
  }
}

Nach dem verschachtelten Zeug kommt nichts mehr. Und die gleiche Reihenfolge wie oben innerhalb des verschachtelten Selektors gilt.

Schreiben Sie niemals Vendor-Präfixe

Vendor-Präfixe sind eine zeitabhängige Sache. Da sich Browser im Laufe der Zeit aktualisieren, wird die Notwendigkeit dafür wegfallen. Wenn Sie Autoprefixer beim Kompilieren von Sass verwenden, sollten Sie sie niemals schreiben müssen.

Alternativ können Sie @mixins von Bibliotheken wie Compass und Bourbon verwenden. Oder Ihre eigenen erstellen. Obwohl die Verwendung von @mixins für Vendor-Präfixe immer noch weniger praktisch ist als Autoprefixer und immer noch etwas Wartung erfordert, ist es immer noch besser, als alles manuell schreiben zu müssen.

Maximale Verschachtelung: Drei Ebenen tief

.weather {
  .cities {
    li {
      // no more!
    }
  }
}

Wahrscheinlich schreiben Sie, wenn Sie tiefer gehen, einen schlechten Selektor. Schlecht, weil er zu stark von der HTML-Struktur abhängt (fragil), übermäßig spezifisch ist (zu mächtig) und nicht wiederverwendbar ist (nicht nützlich). Außerdem ist er an der Grenze zur Schwierigkeit der Verständlichkeit.

Wenn Sie wirklich Tag-Selektoren verwenden möchten, weil Ihnen die Klassenfamilie zu viel wird, sollten Sie sich ziemlich genau darauf festlegen, um unerwünschte Kaskaden zu vermeiden. Und möglicherweise sogar @extend nutzen, damit es auf der CSS-Seite den Vorteil der Wiederverwendbarkeit hat.

.weather
  > h3 {
    @extend %line-under;
  }
}

Maximale Verschachtelung: 50 Zeilen

Wenn ein verschachtelter Sass-Block länger als das ist, besteht eine gute Chance, dass er nicht auf einen Code-Editor-Bildschirm passt und schwer zu verstehen wird. Der Sinn der Verschachtelung ist Komfort und Unterstützung bei der mentalen Gruppierung. Verwenden Sie sie nicht, wenn sie schadet.

Globale und abschnittsspezifische Sass-Dateien sind nur Inhaltsverzeichnisse

Mit anderen Worten, keine Stile direkt darin. Zwingen Sie sich, alle Stile in Komponenten aufzuteilen.

Listen Sie zuerst Vendor/Global Dependencies auf, dann Author Dependencies, dann Patterns, dann Parts

Es ergibt sich ein leicht verständliches Inhaltsverzeichnis.

/* Vendor Dependencies */
@import "compass";

/* Authored Dependencies */
@import "global/colors";
@import "global/mixins";

/* Patterns */
@import "global/tabs";
@import "global/modals";

/* Sections */
@import "global/header";
@import "global/footer";

Die Abhängigkeiten wie Compass, Farben und Mixins erzeugen keine kompilierte CSS überhaupt, sie sind rein code-basierte Abhängigkeiten. Das Auflisten der Patterns als Nächstes bedeutet, dass spezifischere "Parts", die danach kommen, die Macht haben, Patterns zu überschreiben, ohne einen Spezifitätskrieg zu führen.

Teilen Sie in so viele kleine Dateien auf, wie sinnvoll ist

Es gibt keine Nachteile, in viele kleine Dateien aufzuteilen. Tun Sie es so viel, wie es sich für das Projekt gut anfühlt. Ich persönlich finde es einfacher, zu kleinen spezifischen Dateien zu springen und sie zu durchsuchen, als wenige/größere.

...

@import "global/header/header/";
@import "global/header/logo/";
@import "global/header/dropdowns/";
@import "global/header/nav/";
@import "global/header/really-specific-thingy/";

Ich würde dies wahrscheinlich direkt in der global.scss tun, anstatt dass global _header.scss importiert, was eigene Unterimporte hat. All diese Unterimporte könnten außer Kontrolle geraten.

Globbing könnte helfen, wenn es zu viele werden, um sie aufzulisten.

Partials werden _partial.scss genannt

Dies ist eine gängige Namenskonvention, die anzeigt, dass diese Datei nicht eigenständig kompiliert werden soll. Sie hat wahrscheinlich Abhängigkeiten, die eine eigenständige Kompilierung unmöglich machen. Persönlich mag ich Bindestriche im "eigentlichen" Dateinamen, wie z. B. _dropdown-menu.scss.

Lokal mit Source Maps kompilieren

In der Entwicklung ist es wahrscheinlich egal, in welchem Format Sie Ihr Sass kompilieren (z. B. expanded, compressed usw.), solange Sie Source Maps erzeugen.

Es ist eine Option, wenn Sie Sass kompilieren

$ sass sass/screen.scss:stylesheets/screen.css --sourcemap

Obwohl Sie Sass wahrscheinlich nicht typischerweise so kompilieren, gibt es immer eine Möglichkeit, die von Ihnen verwendete Sache zum Kompilieren von Sass so zu konfigurieren, dass sie mit Source Maps funktioniert. Wenn Sie sie haben, bedeutet das, dass DevTools Ihnen zeigt, wo sich der Sass-Code befindet, was super (duper) nützlich ist.

Hier sind einige relevante Links dazu

• (Google) Arbeiten mit CSS-Präprozessoren
• (The Sass Way) Verwenden von Source Maps mit Sass 3.3

Im Deployment kompilieren Sie komprimiert

Live-Websites sollten nur komprimierte CSS enthalten. Und mit Gzip und weit hergeholten Ablaufdaten-Headern obendrein.

Commiten Sie nicht einmal .css-Dateien

Dies erfordert möglicherweise etwas DevOps-Arbeit, aber es ist ziemlich nett, wenn .css-Dateien nicht einmal in Ihrem Repository enthalten sind. Die Kompilierung erfolgt während des Deployments. So sehen Sie im Repository nur Ihre schön formatierten, von Hand geschriebenen Sass-Dateien. Das macht auch die Diffs nützlich. Ein Diff ist eine Vergleichsansicht dessen, was sich geändert hat, die von Versionskontrollanbietern bereitgestellt wird. Der Diff für eine komprimierte CSS-Datei ist nutzlos.

Seien Sie großzügig mit Kommentaren

Es ist selten, dass man es bereut, einen Kommentar im Code hinterlassen zu haben. Er ist entweder hilfreich oder leicht zu ignorieren. Kommentare werden beim Kompilieren zu komprimiertem Code entfernt, sodass keine Kosten entstehen.

.overlay {
  // modals are 6000, saving messages are 5500, header is 2000
  z-index: 5000; 
}

Und wo wir gerade von Kommentaren sprechen, sollten Sie sich vielleicht auf eine Standardisierung einigen. Die // Syntax in Sass ist ziemlich praktisch, besonders für Kommentarblöcke, sodass es einfacher ist, einzelne Zeilen zu kommentieren/entkommentieren.

Variablisieren Sie alle häufig verwendeten Zahlen und Zahlen mit Bedeutung

Wenn Sie eine Zahl häufiger als 0 oder 100% verwenden, verdient sie wahrscheinlich eine Variable. Da sie wahrscheinlich Bedeutung hat und Konsistenz steuert, kann es nützlich sein, sie in Massen ändern zu können.

Wenn eine Zahl eindeutig eine starke Bedeutung hat, ist das ebenfalls ein Anwendungsfall für die Variablisierung.

$zHeader: 2000;
$zOverlay: 5000;
$zMessage: 5050;

.header {
  z-index: $zHeader;
}
.overlay {
  z-index: $zOverlay;
}
.message {
  z-index: $zMessage;
}

Idealerweise sollten diese Zahlen wahrscheinlich in einer separaten Datei gespeichert und als Abhängigkeit @importiert werden. So können Sie Ihren gesamten z-Index-Stack an einem Ort nachverfolgen. Wenn die Variablen jedoch an die Klasse gebunden sind, macht es Sinn, sicherzustellen, dass sie vor allen anderen Regeln stehen.

.accordion {
  $accordion-header-color: $primary-color;
  $accordion-padding: 1em;
  
  @extend %module;
  @include transition(all 0.3s ease-out);
  background: $accordion-header-color;
  padding: $accordion-padding;
}

Variablisieren Sie alle Farben

Außer vielleicht Weiß und Schwarz. Wahrscheinlich ist eine Farbe kein Einzelfall, und selbst wenn Sie denken, dass sie es ist, sobald sie in einer Variablen ist, sehen Sie vielleicht anderswo Verwendungen dafür. Variationen dieser Farbe können oft mit den Sass- Farbfunktionen wie lighten() und darken() behandelt werden – was das Aktualisieren von Farben erleichtert (an einer Stelle ändern, das gesamte Farbschema aktualisiert sich).

Verschachteln und benennen Sie Ihre Media Queries

Die Möglichkeit, Media Queries in Sass zu verschachteln, bedeutet 1) dass Sie den Selektor nicht woanders neu schreiben müssen, was fehleranfällig sein kann, und 2) dass die Regeln, die Sie überschreiben, sehr klar und offensichtlich sind, was normalerweise nicht der Fall ist, wenn sie am Ende Ihres CSS oder in einer anderen Datei stehen.

.sidebar {
  float: right;
  width: 33.33%;
  @include bp(mama-bear) {
    width: 25%;
  }
}

Mehr dazu und die Bedeutung, sie gut zu benennen.

Scham zuletzt

In Ihrem globalen Stylesheet importieren Sie eine _shame.scss-Datei zuletzt.

@import "compass"

...

@import "shame"

Wenn Sie eine schnelle Korrektur vornehmen müssen, können Sie dies hier tun. Später, wenn Sie richtige Zeit haben, können Sie die Korrektur in die richtige Struktur/Organisation verschieben. Siehe mehr.

Das Endergebnis liegt bei Ihnen

Sass tut nichts, was Sie ihm nicht sagen, also ist die Behauptung, dass Sass-Output aufgebläht ist, nur die Behauptung, dass Sie aufgeblähten Code schreiben. Schreiben Sie Sass so, dass der endgültige CSS-Output genau so ist, wie Sie ihn ohne Sass geschrieben hätten.