Sass Guidelines

Syntax & Formatierung

Wenn du mich fragst, sollte dass erste sein was ein Styleguide definiert, die Art und Weise wie der Code aussehen soll.

Wenn mehrere Entwickler in einem Projekt CSS schreiben, ist es nur eine Frage der Zeit bis einer anfängt etwas so zu machen wie er es für gut hält. Konsistente Code Guidelines verhindern dies nicht nur, sondern helfen auch wenn es darum geht den Code zu lesen und zu aktualisieren.

Grob gesehen wollen wir (schamlos inspiriert bei CSS Guidelines):

• zwei (2) Spaces einrücken, keine Tabs;
• idealerweise 80-Buchstaben lange Zeilen;
• ordentlich geschriebene, mehrzeilige CSS Regeln;
• sinnvoller Gebrauch von Leerzeichen.

// Yep
.foo {
  display: block;
  overflow: hidden;
  padding: 0 1em;
}

// Nope
.foo {
    display: block; overflow: hidden;

    padding: 0 1em;
}

// Seit Sass' vorgesehene Syntax diese Standards erzwingt
// gibt es keinen falschen Weg weiterzumachen
.foo
  display: block
  overflow: hidden
  padding: 0 1em

Strings

Ob du es glaubst oder nicht, Strings spielen eine große Rolle in CSS und Sass. Die meisten Werte in CSS sind entweder Zahlen oder Identifikatoren. Deshalb ist es wichtig sich an gewisse Guidelines zu halten, wenn Strings in Sass verwendet werden.

Encoding

Um potentielle Probleme in der Zeichenkodierung zu vermeiden, empfehle ich UTF-8 durch die @charset Regel im Main Stylesheet zu erzwingen. Versicher dich, dass es die allererste Regel in deinem Stylesheet ist, und nichts davor kommt.

@charset 'utf-8';

@charset 'utf-8'

Anführungszeichen

CSS setzt nicht voraus dass Strings in Anführungszeichen zu setzen sind, nichtmal jene die Leerzeichen beinhalten. Zum Beispiel font-family: für den CSS Parser ist es vollkommen egal ob du die Namen in Anführunsgzeichen setzt oder nicht.

Deshalb ist es in Sass ebenfalls nicht nötig. Noch besser (und zum Glück, wie du zugeben musst), ein String in Anführungszeichen ist exakt identisch gegenüber einem String ohne (z.B. 'abc' ist exakt gleich zu abc).

Im übrigen sind Sprachen die es nicht erfordern Strings in Anführungszeichen zu setzen eine Minderheit, deshalb sollten Strings in Sass immer in einfachen Anführungszeichen (') gesetzt werden (sie sind einfacher zu tippen als die normalen auf einer QWERTY Tastatur). Neben der Einheitlichkeit zu anderen Sprachen, einschließlich CSS’ Cousin JavaScript, gibt es mehrere Gründe dafür:

• Farbnamen werden wie Farben interpretiert wenn sie in Anführungszeichen gesetzt sind, was zu ernsthaften Problemen führen kann;
• die meisten Syntax-Highlighter bekommen Probleme mit Strings die nicht in Anführungszeichen stehen;
• es unterstützt die generelle Lesbarkeit;
• es gibt keinen wirklichen Grund es nicht zu tun.

// Yep
$direction: 'left';

// Nope
$direction: left;

// Yep
$direction: 'left'

// Nope
$direction: left

Strings als CSS Werte

Bestimmte CSS Werte (Identifikatoren) wie initial oder sans-serif müssen nicht in Anführungszeichen stehen. Tatsächlich wird CSS unbemerkt versagen, wenn font-family: 'sans-serif' benutzt wird, da es einen Identifier erwartet und keinen String. Deshalb setzen wir diese Werte nicht in Anführungszeichen.

// Yep
$font-type: sans-serif;

// Nope
$font-type: 'sans-serif';

// Okay I guess
$font-type: unquote('sans-serif');

// Yep
$font-type: sans-serif

// Nope
$font-type: 'sans-serif'

// Okay I guess
$font-type: unquote('sans-serif')

Deshalb können wir zwischen Strings die wie im vorigen Beispiel als CSS Werte (CSS Identifier) vorgesehen sind, und Strings die sich in Sass auf Datentypen wie beispielsweise Map Keys beziehen, unterscheiden.

Wir setzen ersteres nicht in Anführungszeichen, aber letzteres in einfache.

Strings die Anführungszeichen beinhalten

Wenn ein String mehrere einfache Anführungszeichen beinhaltet, mag man drüber nachdenken diese in doppelte (") zu setzen, um zu vermeiden Zeichen escapen zu müssen.

// Okay
@warn 'You can\'t do that.';

// Okay
@warn "You can't do that.";

// Okay
@warn 'You can\'t do that.'

// Okay
@warn "You can't do that."

URLs

URLs sollten aus denselben Gründen wie oben in Anführungszeichen gesetzt werden:

// Yep
.foo {
  background-image: url('/images/kittens.jpg');
}

// Nope
.foo {
  background-image: url(/images/kittens.jpg);
}

// Yep
.foo
  background-image: url('/images/kittens.jpg')

// Nope
.foo
  background-image: url(/images/kittens.jpg)

Zahlen

In Sass sind Zahlen ein Datentyp der alles von einheitlosen Zahlen über Längen, Dauer, Frequenzen, Winkel und so weiter, beinhalten kann. Das erlaubt es dementsprechende Berechnung zu machen.

Nullen

Zahlen sollten immer eine Null vor dezimalen Werten, die weniger als eins sind, anzeigen. Eine Null niemals hinten anhängen.

// Yep
.foo {
  padding: 2em;
  opacity: 0.5;
}

// Nope
.foo {
  padding: 2.0em;
  opacity: .5;
}

// Yep
.foo
  padding: 2em
  opacity: 0.5

// Nope
.foo
  padding: 2.0em
  opacity: .5

Einheiten

Wenn es um Längen geht, sollte eine 0 niemals eine weitere Einheit besitzen.

// Yep
$length: 0;

// Nope
$length: 0em;

// Yep
$length: 0

// Nope
$length: 0em

Der häufigste Fehler den ich mir bei Zahlen in Sass vorstellen kann, ist der Gedanke dass Einheiten einfach nur ein String sind, die man sicher zu jeder Zahl hinzufügen kann. Das klingt zwar richtig, ist aber nicht wie Einheiten funktionieren. Stell dir eine Einheit als ein algebraisches Symbol vor. Zum Beispiel in der echten Welt, ist 5 Zoll multipliziert mit 5 Zoll gleich 25 Quadratzoll. Nach derselben Logik geht Sass.

Um eine Einheit zu einer Zahl hinzuzufügen, musst du diese Zahl mit einer Einheit multiplizieren.

$value: 42;

// Yep
$length: $value * 1px;

// Nope
$length: $value + px;

$value: 42

// Yep
$length: $value * 1px

// Nope
$length: $value + px

Einen 0 Wert der Einheit hinzuzufügen funktioniert ebenfalls, aber ich empfehle eher die obrige Methode da es sonst etwas verwirrend ist. Wenn du versuchst eine Zahl in eine andere kompatible Einheit zu konvertieren, wird 0 hinzuzufügen nicht klappen. Mehr dazu in diesem Artikel.

$value: 42 + 0px;
// -> 42px

$value: 1in + 0px;
// -> 1in

$value: 0px + 1in;
// -> 96px

$value: 42 + 0px
// -> 42px

$value: 1in + 0px
// -> 1in

$value: 0px + 1in
// -> 96px

Am Ende kommt es wirklich darauf an was du erreichen möchtest. Versuch dich einfach daran zu erinnern, das eine Einheit als String hinzuzufügen kein guter Weg ist fortzufahren.

Um die Einheit von einem Wert zu entfernen, musst du es um eine Einheit seiner Art teilen.

$length: 42px;

// Yep
$value: $length / 1px;

// Nope
$value: str-slice($length + unquote(''), 1, 2);

$length: 42px

// Yep
$value: $length / 1px

// Nope
$value: str-slice($length + unquote(''), 1, 2)

Eine Einheit als String zu einer Zahl hinzuzufügen, macht sie zu einem String. Dadurch sind alle weiteren Operationen mit dem Wert nicht mehr möglich. Den numerischen Teil einer Einheit zu trennen, führt ebenfalls zu einem String. Das ist nicht was du willst. Benutze Längen, keine Strings.

Berechnungen

Numerische Berechnungen auf höchser Ebene sollten immer in Klammern stehen. Es erhöht nicht nur enorm die Lesbarkeit, sondern umgeht auch Edge Cases indem Sass gezwungen wird den Inhalt von Klammern zu erst zu berechnen.

// Yep
.foo {
  width: (100% / 3);
}

// Nope
.foo {
  width: 100% / 3;
}

// Yep
.foo
  width: (100% / 3)

// Nope
.foo
  width: 100% / 3

Magische Zahlen

“Magische Zahlen” sind in der Old School Programmierung ein Term dafür, Werte direkt im Quellcode zu benutzen. Grundsätzlich erklärt, ist es eine zufällige Zahl die einfach funktioniert™ ohne an irgendeine logische Begründung gebunden zu sein.

Magische Zahlen sind schlechter Programmierstil und sollten unter allen Umständen vermieden werden. Falls du mal keine gute Erklärung finden kannst, weshalb eine Zahl funktioniert, dann füg ein ausführlichen Kommentar hinzu der erklärt wie du dahin gekommen bist und weshalb du denkst dass es funktioniert. Zuzugeben dass du nicht weißt weshalb etwas funktioniert, ist manchmal hilfreicher für den nächsten Entwickler als wenn er komplett von Anfang herausfinden muss was passiert.

/**
 * 1. Magische Zahl. Das ist der niedrigste Wert den ich finden konnte,
 * um die Höhe von `.foo` zu seinem Elternelement auszurichten.
 * Idealerweise sollten wir das beheben.
 */
.foo {
  top: 0.327em; /* 1 */
}

/**
 * 1. Magische Zahl. Das ist der niedrigste Wert den ich finden konnte,
 * um die Höhe von `.foo` zu seinem Elternelement auszurichten.
 * Idealerweise sollten wir das beheben.
 */
.foo
  top: 0.327em /* 1 */

Zu dem Thema hat CSS-Tricks einen hervoragenden Artikel über magische Zahlen in CSS den ich dir nur empfehlen kann.

Farben

Farben nehmen einen wichtigen Platz in der CSS Sprache ein. Normalerweise ist Sass ein wertvoller Verbündeter wenn es darum geht Farben zu manipulieren. Meistens dadurch mächtige Funktionen bereit zu stellen.

Sass ist so nützlich Farben zu manipulieren dass das Internet voller Artikel über das Thema aufblüht. Lass mich ein paar Artikel empfehlen:

• How to Programmatically Go From One Color to Another
• Using Sass to Build Color Palettes
• Dealing with Color Schemes in Sass

Farbformate

Um Farben so einfach wie sie sind zu lassen, ist mein Ratschlag folgende Reihenfolge bei Farbformaten zu respektieren:

1. HSL-Farbraum;
2. RGB-Farbraum;
3. Hexadezimale Darstellung (Kleinbuchstaben und gekürzt).

CSS Farbkeywords sollten nur für schnelles Prototyping verwendet werden. Es sind zwar englische Wörter, jedoch haben manche eine wirklich schlechte Beschreibung der Farbe die sie repräsentieren, was vor allem für nicht englischsprachige ein Problem sein kann. Darüber hinaus sind Keywords nicht perfekt semantisch; zum Beispiel ist grey in Wirklichkeit dunkler als darkgrey und die Verwirrung zwischen grey und gray kann zu inkonsistenter Verwendung der Farbe führen.

Der HSL-Farbraum ist nicht nur am einfachsten für das menschliche Gehirn zu verstehen^{[Zitat benötigt]}, sondern er macht es außerdem ziemlich leicht für Stylesheet-Autoren Farben durchs anpassen des Farbton, der Sättigung und Helligkeit zu optimieren.

RGB hingegen hat immernoch den Vorteil direkt zu zeigen ob eine Farbe mehr in Richtung Blau, Grün oder Rot geht. Es ist jedoch nicht einfach eine Farbe aus den drei Komponenten zu erstellen.

Zuletzt, Hexadezimale Darstellung ist schwer lesbar für das menschliche Gedächtnis.

// Yep
.foo {
  color: hsl(0, 100%, 50%);
}

// Also yep
.foo {
  color: rgb(255, 0, 0);
}

// Meh
.foo {
  color: #f00;
}

// Nope
.foo {
  color: #FF0000;
}

// Nope
.foo {
  color: red;
}

.foo
  color: hsl(0, 100%, 50%)

// Also yep
.foo
  color: rgb(255, 0, 0)

// Nope
.foo
  color: #f00

// Nope
.foo
  color: #FF0000

// Nope
.foo
  color: red

Wenn der HSL oder RGB-Farbaum verwendet wird, füge immer ein Leerzeichen nach dem Komma (,) hinzu, und keines zwischen Klammern und Inhalt ((, )).

// Yep
.foo {
  color: rgba(0, 0, 0, 0.1);
  background: hsl(300, 100%, 100%);
}

// Nope
.foo {
  color: rgba(0,0,0,0.1);
  background: hsl( 300, 100%, 100% );
}

// Yep
.foo
  color: rgba(0, 0, 0, 0.1)
  background: hsl(300, 100%, 100%)

// Nope
.foo
  color: rgba(0,0,0,0.1)
  background: hsl( 300, 100%, 100% )

Farben und Variablen

Wenn du eine Farbe mehr als einmal verwendest, speicher sie in einer sinnvoll benannten Variable.

$sass-pink: hsl(330, 50%, 60%);

$sass-pink: hsl(330, 50%, 60%)

Nun kannst du die Variable überall verwenden wo du willst. Wenn du aber stark an ein Theme gebunden bist, würde ich gegen diese Nutzung von Variablen argumentieren. Stattdessen, speicher die Variable in einer weiteren wo der Name erklärt wie sie eingesetzt werden soll.

$main-theme-color: $sass-pink;

$main-theme-color: $sass-pink

Dadurch verhinderst du auch bei einem Themewechsel etwas wie $sass-pink: blue machen zu müssen. Dieser Artikel erledigt einen guten Job darin zu erklären weshalb es wichtig ist deine Farbvariablen durchzudenken.

Farben aufhellen und verdunkeln

Beide lighten und darken Funktionen manipulieren die Helligkeit einer Farbe im HSL-Farbraum durch hinzufügen oder entfernen von Helligkeit. Grundsätzlich sind sie nicht als Pseudonyme für den $lightness Parameter der adjust-color Funktion.

Das Ding ist, dass solche Funktionen oft nicht das erwartete Ergebnis liefern. Auf der anderen Seite ist die mix Funktion ein netter Weg um eine Farbe durchs mischen mit white oder black aufzuhellen oder zu verdunkeln.

Der Vorteil von mix ist weder die oben genannten Funktionen, sondern dass es stufenweise ins Schwarz (oder Weiß) geht, je nachdem wie du das Verhältnis der Farbe verringerst. Wobei darken und lighten relativ schnell die Farbe ins Schwarz oder Weiß ausbleichen.

Wenn du nicht jedesmal die mix Funktion schreiben möchtest, kannst du dir auch zwei einfach zu verwendene Funktionen namens tint und shade (welche ebenfalls zu Compass dazu gehören) schreiben, um genau dasselbe zu erreichen:

/// Hellt eine Farbe leicht auf
/// @access public
/// @param {Color} $color - zu färbende Farbe
/// @param {Number} $percentage - Prozent von `$color` welcher die Farbe wiedergegeben werden soll
/// @return {Color}
@function tint($color, $percentage) {
  @return mix(white, $color, $percentage);
}

/// Verdunkelt eine Farbe leicht
/// @access public
/// @param {Color} $color - zu verdunkelnde Farbe
/// @param {Number} $percentage - Prozent von `$color` welcher die Farbe wiedergegeben werden soll
/// @return {Color}
@function shade($color, $percentage) {
  @return mix(black, $color, $percentage);
}

/// Hellt eine Farbe leicht auf
/// @access public
/// @param {Color} $color - zu färbende Farbe
/// @param {Number} $percentage - Prozent von `$color` welcher die Farbe wiedergegeben werden soll
/// @return {Color}
@function tint($color, $percentage)
  @return mix($color, white, $percentage)

/// Verdunkelt eine Farbe leicht
/// @access public
/// @param {Color} $color - zu verdunkelnde Farbe
/// @param {Number} $percentage - Prozent von `$color` welcher die Farbe wiedergegeben werden soll
/// @return {Color}
@function shade($color, $percentage)
  @return mix($color, black, $percentage)

Listen

Listen sind Sass’ äquivalent zu Arrays. Eine Liste ist eine flache Datenstruktur (anders als Maps), vorgesehen um Werte jeden Typs (einschließlich Listen, was zu verschachtelten Listen führt) zu speichern.

Listen sollten folgende Guidelines beachten:

• entweder einzeilig oder mehrzeilig;
• auf jedenfall mehrzeilig wenn sie mehr als 80 Zeichen beinhalten;
• es sei denn sie sind für CSS Zwecke verwendet, immer mit einem Komma getrennt;
• immer in Klammern;
• ein abschließendes Komma wenn mehrzeilig, keines wenn einzeilig.

// Yep
$font-stack: ('Helvetica', 'Arial', sans-serif);

// Yep
$font-stack: (
  'Helvetica',
  'Arial',
  sans-serif,
);

// Nope
$font-stack: 'Helvetica' 'Arial' sans-serif;

// Nope
$font-stack: 'Helvetica', 'Arial', sans-serif;

// Nope
$font-stack: ('Helvetica', 'Arial', sans-serif,);

// Yep
$font-stack: ('Helvetica', 'Arial', sans-serif)

// Nope (not supported)
$font-stack: (
  'Helvetica',
  'Arial',
  sans-serif,
)

// Nope
$font-stack: 'Helvetica' 'Arial' sans-serif

// Nope
$font-stack: 'Helvetica', 'Arial', sans-serif

// Nope
$font-stack: ('Helvetica', 'Arial', sans-serif,)

Wenn neue Inhalte zu einer Liste hinzugefügt werden sollen, dann verwende immer die vorgesehene API. Füg sie nicht manuell hinzu.

$shadows: (0 42px 13.37px hotpink);

// Yep
$shadows: append($shadows, $shadow, comma);

// Nope
$shadows: $shadows, $shadow;

$shadows: (0 42px 13.37px hotpink)

// Yep
$shadows: append($shadows, $shadow, comma)

// Nope
$shadows: $shadows, $shadow

Weitere Informationen:

+In diesem Artikel gehe ich durch eine Menge Tipps und Tricks wie man Listen in Sass korrekt benutzt und manipuliert.

Maps

Mit Sass können Stylesheet Autoren sogenannte Maps definieren — der Sass Term für assoziative Arrays, Hashes oder sogar JavaScript Objects. Eine Map ist eine Datenstruktur welche Keys mit Werten vereinigt. Keys und Werte können von jedem Typ, einschließlich Maps, sein. Ich empfehle aber nicht solch komplexe Datentypen als Map-Keys zu verwenden, nur weil es möglich ist.

Maps sollten folgendermaßen geschrieben werden:

• Leerzeichen nach Doppelpunkt (:);
• öffnende Klammer (() auf derselben Zeile wie der Doppelpunkt (:);
• Keys in Anführungszeichen wenn sie Strings sind (was zu 99% der Fall ist);
• jedes Key/Value Paar auf eine neue Zeile;
• Komma (,) ans Ende von jedem Key/Value;
• abschließendes Komma (,) ans letzte Element um das hinzufügen, entfernen oder neuordnen einfacher zu machen;
• schließende Klammer ()) auf eine neue Zeile;
• kein Leerzeichen oder neue Zeile zwischen schließender Klammer ()) und Semikolon (;)

Illustration:

// Yep
$breakpoints: (
  'small': 767px,
  'medium': 992px,
  'large': 1200px,
);

// Nope
$breakpoints: ( small: 767px, medium: 992px, large: 1200px );

// Yep
$breakpoints: ('small': 767px, 'medium': 992px, 'large': 1200px,)

// Nope
$breakpoints: ( 'small': 767px, 'medium': 992px, 'large': 1200px )

// Nope
$breakpoints: (small: 767px, medium: 992px, large: 1200px,)

// Nope (since it is not supported)
$breakpoints: (
  'small': 767px,
  'medium': 992px,
  'large': 1200px,
)

Artikel über Sass Maps zeigen wie lang ersehnt dieses Feature war. Ich kann diese 3 Artikel empfehlen: Using Sass Maps, Extra Map functions in Sass, Real Sass, Real Maps.

CSS Regelwerk

An diesem Punkt, ist es hauptsächlich nur noch ein Überarbeiten von dem was jeder schon weiß, aber hier haben wir wie CSS Regelwerke geschrieben werden sollten (zumindest, nach den meisten Guidelines, einschließlich CSS Guidelines):

• verwandte Selektoren auf dieselbe Zeile; zusammenhanglose auf eine neue;
• die öffnende Klammer ({) mit einem Leerzeichen zum letzten Selektor;
• jede Deklaration auf eine neue Zeile;
• ein Leerzeichen nach dem Doppelpunkt (:);
• ein abschließendes Semikolon (;) ans Ende aller Deklarationen;
• die schließende Klammer (}) auf eine neue Zeile;
• eine neue Zeile nach der schließenden Klammer (}).

Illustration:

// Yep
.foo, .foo-bar,
.baz {
  display: block;
  overflow: hidden;
  margin: 0 auto;
}

// Nope
.foo,
.foo-bar, .baz {
    display: block;
    overflow: hidden;
    margin: 0 auto }

// Yep
.foo, .foo-bar,
.baz
  display: block
  overflow: hidden
  margin: 0 auto

// Nope
.foo,
.foo-bar, .baz
    display: block
    overflow: hidden
    margin: 0 auto

Zusätzlich zu den CSS bezogenen Guidelines, richtet sich unsere Aufmerksamkeit auf:

• lokale Variablen sollen vor allen anderen Deklarationen zugewiesen und durch eine neue Zeile getrennt werden;
• Mixin Aufrufe die kein @content besitzen, kommen vor alle Deklarationen;
• verschachtelte Selektoren immer in eine neue Zeile;
• Mixin-Aufrufe mit @content kommen nach jedem verschachtelten Selektor;
• keine neue Zeile nach der schließenden Klammer (}).

Illustration:

.foo, .foo-bar,
.baz {
  $length: 42em;

  @include ellipsis;
  @include size($length);
  display: block;
  overflow: hidden;
  margin: 0 auto;

  &:hover {
    color: red;
  }

  @include respond-to('small') {
    overflow: visible;
  }
}

.foo, .foo-bar,
.baz
  $length: 42em

  +ellipsis
  +size($length)
  display: block
  overflow: hidden
  margin: 0 auto

  &:hover
    color: red

  +respond-to('small')
    overflow: visible

Anordnung der Deklarationen

Ich kann mir kein Thema vorstellen, wo die Meinungen am weitesten außeinander gehen als bei der Anordnung von Deklarationen in CSS. Konkret gibt es zwei Fraktionen:

• sich an eine alphabetische Reihenfolge halten;
• Deklarationen nach Typ (position, display, colors, font, sonstiges…) sortieren.

Es gibt bei beidem Vor- und Nachteile. Auf der einen Seite ist die alphabetische Reihenfolge universal (zumindest für Sprachen mit dem lateinischen Alphabet), also gibt es auch keine Diskussion darüber wie Werte sortiert werden sollen. Dennoch kommt es mir ziemlich komisch vor, Werte wie bottom und top nicht direkt beieinander zu sehen. Warum sollen Animationen vor dem Display-Typ erscheinen? Es gibt eine Menge Ungereimtheiten mit der alphabetischen Reihefolge.

.foo {
  background: black;
  bottom: 0;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
  height: 100px;
  overflow: hidden;
  position: absolute;
  right: 0;
  width: 100px;
}

.foo
  background: black
  bottom: 0
  color: white
  font-weight: bold
  font-size: 1.5em
  height: 100px
  overflow: hidden
  position: absolute
  right: 0
  width: 100px

Auf der anderen Seite macht die Sortierung nach Typ perfekt Sinn. Jede font bezogene Deklaration ist gesammelt, top und bottom sind beisammen und ein Regelwerk zu lesen fühlt sich einfach an wie eine Kurzgeschichte. Aber solange du dich an Konventionen wie Idiomatic CSS hälst, gibt es eine Menge Spielraum für Interpretationen wie man etwas machen soll. Wo gehört white-space hin: font oder display? Wozu gehört overflow nun wirklich? Was ist die Reihenfolge innerhalb einer Gruppe (es könnte alphabetisch sein, welch Ironie)?

.foo {
  height: 100px;
  width: 100px;
  overflow: hidden;
  position: absolute;
  bottom: 0;
  right: 0;
  background: black;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
}

.foo
  height: 100px
  width: 100px
  overflow: hidden
  position: absolute
  bottom: 0
  right: 0
  background: black
  color: white
  font-weight: bold
  font-size: 1.5em

Es gibt noch einen weiteren Ansatz bei der Sortierung nach Typ, genannt Concentric CSS, welcher ebenfalls ziemlich bekannt zu sein scheint. Grundsätzlich richtet sich Concentric CSS an das box-model um die Reihenfolge zu definieren: von außen nach innen.

.foo {
  width: 100px;
  height: 100px;
  position: absolute;
  right: 0;
  bottom: 0;
  background: black;
  overflow: hidden;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
}

.foo
  width: 100px
  height: 100px
  position: absolute
  right: 0
  bottom: 0
  background: black
  overflow: hidden
  color: white
  font-weight: bold
  font-size: 1.5em

Ich kann mich selber nicht entscheiden. Eine kürzliche Umfrage auf CSS-Tricks kam zum Schluss dass über 45% der Entwickler ihre Deklarationen nach Typ sortieren, wobei nur 14% die alphabetische Reihenfolge verwenden. Gleichzeitig sortieren 39% vollkommen zufällig, mich selbst eingeschlossen.

Deshalb werde ich auch keines davon hier im Styleguide definieren. Nimm das was dir am besten gefällt, solange du konsistent durch alle Stylesheets bleibst (z.B. nicht die Random-Option).

Verschachtelung von Selektoren

Ein bestimmtes Feature von Sass, welches von vielen Entwickler übermäßig missbraucht wird, ist die Verschachtelung von Selektoren. Sie bietet einen Weg für Stylesheet Autoren, lange Selektoren, durchs ineinander verschachteln von kurzen Selektoren, zu erzeugen.

Generelle Regel

Zum Beispiel, folgende Sass Verschachtelung:

.foo {
  .bar {
    &:hover {
      color: red;
    }
  }
}

.foo
  .bar
    &:hover
      color: red

… wird dieses CSS generieren:

.foo .bar:hover {
  color: red;
}

Bei den gleichen Zeilen, ist es seit Sass 3.3 möglich die Selektorreferenz (&) zu verwenden um erweiterte Selektoren zu erzeugen. Zum Beispiel:

.foo {
  &-bar {
    color: red;
  }
}

.foo
  &-bar
    color: red

… wird dieses CSS generieren:

.foo-bar {
  color: red;
}

.foo-bar
  color: red

Diese Methode wird oft bei der BEM Namenskonvention verwendet, um .block__element und .block--modifier Selektoren basierend auf dem originalen Selektor zu erzeugen (in diesem Fall .block).

Das Problem mit dem Verschachteln von Selektoren ist, dass es den Code unheimlich schwer lesbar macht. Man muss den entsprechenden Selektor erst gedanklich erzeugen; es ist nicht immer offensichtlich wie das CSS am Ende aussehen wird.

Die Aussage gewinnt an Relevanz, sobald Selektoren immer länger werden und die Verwendung von (&) häufiger. Ab einem gewissen Punkt, ist das Risiko nicht mehr zu verstehen was passiert zu hoch und es nicht wert.

Um dem ganzen also Vorzubeugen, haben wir ein paar Jahre zurück viel über die Inception-Regel gesprochen. Es wird nicht empfohlen mehr als 3 Ebenen tief zu verschachteln, als Referenz zu dem Film Inception von Christopher Nolan. Ich würde drastischer sein und es vermeiden so viel wie möglich Selektoren zu verschachteln.

Es gibt selbsverständlich ein paar Ausnahmen zu dieser Regel wie wir in der nächsten Sektion sehen werden. Diese Meinung scheint ziemlich beliebt zu sein. Du kannst mehr darüber in Beware of Selector Nesting und Avoid nested selectors for more modular CSS lesen.

Ausnahmen

Für Anfänger ist es erlaubt und sogar empfohlen Pseudoklassen und Pseudoelemente innerhalb des Selektors zu verschachteln.

.foo {
  color: red;

  &:hover {
    color: green;
  }

  &::before {
    content: 'pseudo-element';
  }
}

.foo
  color: red

  &:hover
    color: green

  &::before
    content: 'pseudo-element'

Pseudoklassen sowie Pseudoelemente zu verschachteln macht nicht nur Sinn (da es mit nah verwandten Selektoren zu tun hat), es hilft auch alles einer Komponente an einem Platz zu halten.

Es ist ebenfalls absolut in Ordnung, Komponentenbezogene Statusklassen wie .is-active innerhalb des Selektors der Komponenten anzuordnen, einfach um es ordentlich zu halten.

.foo {
  // …

  &.is-active {
    font-weight: bold;
  }
}

.foo
  // …

  &.is-active
    font-weight: bold

Zu guter Letzt, wenn ein Element gestaltet werden muss weil es innerhalb eines weiteren Elements angeordnet ist, ist es ebenso in Ordnung diese zu verschachteln um alles was diese Komponente betrifft am selben Platz zu haben.

.foo {
  // …

  .no-opacity & {
    display: none;
  }
}

.foo
  // …

  .no-opacity &
    display: none

Wie mit allem, ist dieser spezifische Fall irgendwie irrelevant, denn wichtig ist Konsistenz. Wenn du dich also absolut okay mit Verschachtelung von Selektoren fühlst, dann mach es so. Versicher dich nur das auch dein ganzes Team damit einverstanden ist.