Wie wichtig Konventionen sind, muss ich keinem Entwickler erklären. Wenn jeder Variablen benennen oder Code einrücken würde, wie er will, dann wäre jedes Projekt zum Scheitern verurteilt. Da ist auch CSS keine Ausnahme. Damit euer Projekt nicht im Chaos endet und überflüssige Arbeit beim Debuggen vermieden werden kann, sollten einige der folgenden Konventionen eingesetzt werden.

Die Benennung eines Objekts in CSS sollte nicht in Camel-Case erfolgen. Auch wenn das in Javascript so üblich ist, sollte in CSS darauf verzichtet werden. Ein Grund dafür ist die Art und Weise, wie in CSS Eigenschaften benannt sind.

// Falsch
.postTitle {
  font-weight: normal; 
}

Stattdessen sollten Objekte mit Bindestrichen benannt werden:

// Richtig
.post-title {
  font-weight: normal;
}

Doch bei der Namensvergabe eines Objekts gibt es noch einiges mehr zu beachten. Denn für die Benennung von Eltern und zugehörigen Kindern sowie Attributen kann man sich das Leben mit den folgenden Konventionen deutlich leichter machen.

.noun {} // Objekt z.B. .header
.noun {} // Eltern z.B. .post
.noun-noun {} // Kind z.B. .post-title
.adjective-noun {} // Unterklasse von „noun“ z.B. .left-button
// Attribute
.adjective {} // z.B. .inline
.is-state {} // z.B. .is-shown

Da die Unterklasse hier den „button“ nur erweitern soll, werden die Eigenschaften für den normalen Button natürlich nicht erneut beim Beschreiben des linken Buttons wiederholt. Dadurch müssen dem HTML-Element beide Klassen zugeordnet werden:

<button class="button left-button"></button>

Wie bei so vielem gibt es auch bei Konventionen mehr als nur einen Ansatz. Neben der oben genannten „Bindestrich-Schreibweise“ ist auch die sogenannte BEM-Notation eine häufig verwendete Alternative. BEM steht dabei für Block, Element und Modifier. Für eine möglichst einfache Erklärung dieser Konvention ziehen wir ein Auto als Beispiel heran. Dieses wollen wir nun mit passenden Eigenschaften beschreiben. Dabei ist das Auto selbst ein Block.

.car {}

Das „E“ beschreibt die Elemente des Autos. Das können Autoreifen, Türen oder auch die Scheinwerfer sein. Diese werden mit zwei Unterstrichen an den Block angehängt:

.car__wheel {}
.car__door {}
.car__headlight {}

Zu guter Letzt bleibt das „M“. Mit diesem kann das Auto modifiziert werden. Das kann ganz einfach eine Farbe sein. Diese wird dann mit zwei Bindestrichen angehängt:

.car--black {}
.car--blue {}

Doch es können auch die Elemente modifiziert werden. Vielleicht will man – warum auch immer – für seine Autotür eine separate Farbe haben.

.car__door--blue {}
.car__door--orange {}

Mehr Details zu BEM findest du hier.

Angenommen, du verwendest keine separaten Klassen für Javascript, dann verursacht das zwei Probleme. Einerseits riskierst du einen Fehler, wenn du die Klasse umbenennst und vergisst, das im Javascript-Code anzupassen und andererseits kannst du nicht direkt erkennen, ob auf dein HTML-Element innerhalb von Javascript zugegriffen wird. Um beide Probleme zu vermeiden, kann ein einheitlicher, sinnvoller Prefix vor einer weiteren Klasse gesetzt werden:

<button class="button js-button"></button>

Um doppelt und dreifachen CSS-Code zu vermeiden, können CSS-Elemente kombiniert werden.

h1, h2, h3 {
  color: #111;
  font-weight: normal;
}

Eine weitere, sehr gute Möglichkeit, den Code schlanker zu gestalten, sind Eigenschaften wie Padding oder Margin. So kann aus vier Zeilen…

...
padding-top: 5px;
padding-right: 3px;
padding-bottom: 2px;
padding-left: 8px;
...

… eine Zeile Code werden:

...
padding: 5px 3px 2px 8px;
...

Die Kommentarfunktion ist eines der einfachsten und zugleich wichtigsten Werkzeuge für Entwickler, um Code übersichtlicher zu machen. Dennoch gerät sie schnell in Vergessenheit und kostet am Ende mehr Zeit als das Schreiben der Kommentare benötigt hätte.

Um Kommentare in CSS sinnvoll einzusetzen, können zusammengehörige Klassen zu Abschnitten zusammengefasst werden. Diese Abschnitte können dann wunderbar mit passenden Kommentaren versehen werden:

/* COLUMNS */
...
/* HEADER */
...
/* FOOTER */
...

Bei einem kleinen Ein-Mann-Projekt müssen nicht zwangsweise mehrere CSS-Dateien angelegt werden. Doch je größer ein Team und ein Projekt wird, desto wichtiger wird diese Trennung. So arbeiten nicht mehrere Entwickler womöglich gleichzeitig an einer Styles-Datei. Jeder kann so die Verantwortung über einzelne CSS-Dateien erhalten. Eine mögliche Dateistruktur könnten dabei wie folgt aussehen:

• layouts.css: Essentielle Styles für das Seitenlayout
• typography.css: Alles zu Schriften: Textgrößen, Schriftarten, usw.
• forms.css: Alles Wichtige für Formulare
• tables.css: Styles zu Tabellen
• lists.css: Styles zu Listen
• …

Deine Struktur kann sich von dieser natürlich unterscheiden. Sie ist nur ein Beispiel und soll eine grobe Richtung vorgeben. Es ist auf jeden Fall sinnvoll, eine thematisch passende Aufspaltung auf verschiedene Dateien vorzunehmen.

Aber auch eine CSS-Datei an sich sollte eine Struktur haben. Zu empfehlen ist eine Art Top-Down-Struktur: also von wichtig zu unwichtig oder von oben nach unten (bezogen auf das Seitenlayout). So entstehen Abschnitte, die wieder gut kommentiert werden können.

/* HEADER */
...
/* NAVBAR */
...
/* MAIN CONTENT */
...

Die Struktur in der typography.css könnte mit einer entsprechenden Top-Down-Struktur wie folgt aussehen.

/* HEADLINES */
...
h1 { }
h2 { }
...
/* TEXT */
...
/* QUOTES */
...

Die hier aufgezählten Konventionen zeigen letztlich nur einige Möglichkeiten, wie du eine gute Struktur in deinen CSS-Code bekommst. Insgesamt ist es also gar nicht so wichtig, ob du die gelisteten Konventionen bis ins kleinste Detail einhältst. Wirklich wichtig ist nur, sich für eine einheitliche Konvention zu entscheiden und diese auch konsequent einzuhalten. Auch und vor allem, wenn hinter einem Projekt ein ganzes Team steht.

Passend zu dem Thema:

• Mit diesem Guide lernt ihr kostenlos CSS und HTML
• Das sind 10 spannende CSS-Frameworks
• Alles was du über CSS Grid wissen musst