CSS Coding Guidelines – CSS Code besser schreiben, formatieren und organisieren

Von: Jonas

CSS Coding Guidelines helfen euch dabei besseren Code zu schreiben. Wir haben die wichtigsten Infos zusammengefasst.

Aktualisiert von 2016 – 2023 Ein Kommentar

CSS hat eine vergleichsweise einfache Syntax und erlaubt daher einen leichten Einstieg. Dennoch kann CSS in der Organisation schnell komplex werden. Das gilt besonders für größere Projekte mit mehreren involvierten Entwicklern, aber auch für kleine und mittlere Projekte in Eigenverantwortung. In diesem Beitrag fassen wir einige Tipps zusammen, die euch helfen sollen besseren CSS-Code zu schreiben.

Grundlagen für gute CSS-Qualität

Die Kunst beim Schreiben von gutem CSS liegt darin, mit möglichst wenig Code genau das Styling zu erreichen was erreicht werden soll, ohne dass an anderer Stelle unerwünschte Nebeneffekte auftreten. Die zahlreichen Möglichkeiten CSS-Selektoren zu schreiben sollten euch bekannt sein. Eine detaillierte Übersicht haben wir in einem eigenen Beitrag zum Thema CSS-Selektoren zusammengefasst.

Darüber hinaus muss bekannt sein, wie das »Punktesystem« – die sog. CSS Spezifität – bei der Gewichtung von CSS-Selektoren funktioniert. Lest dazu unseren umfangreichen Beitrag zum Thema CSS-Spezifität.

Aus diesen Basics können folgende Grundregeln abgeleitet werden:

• Wenig verschachteln. Ketten wie  nav ul li a sollen, wenn möglich vermieden werden
• Über Klassen (.class) stylen
• Keine IDs (#id) für das Styling benutzen
• !important ist verboten

Insbesondere beim Einsatz eines CSS-Präprozessors wie Sass muss darauf geachtet werden, dass keine tiefen Verschachtelungen entstehen.

CSS Style scoping – Konflikte vermeiden

Zusätzlich solltet ihr darauf achten, dass keine Konflikte mit fremdem CSS-Code entstehen können. Dieser fremde Code kann von einem Kollegen geschrieben sein, kommt häufig aber auch von Content Management Systemen, Plugins usw. Eure CSS-Stile sollten immer vom Wirkungsbereich klar fokussiert sein. Man spricht daher auch von »Style Scoping«.

Folgende Techniken sind grundsätzlich empfehlenswert um Konflikte unwahrscheinlicher zu machen:

CSS Klassen richtig benennen

Keine darstellungsbezogenen Namen für CSS-Klassen verwenden. .button-red funktioniert beispielsweise nicht mehr, wenn der Button umgefärbt werden soll. .button-primary hingegen schon, da der Name aus funktionaler/inhaltlicher Sicht gewählt wurde

Sinnabschnitte auf einzelne Dateien aufteilen

Einzelne funktionale Bereiche der Website sollten in einzelnen CSS-Dateien organisiert werden. Das erhöht die Übersicht und vereinfacht das parallele Arbeiten mehrerer Entwickler an verschiedenen Bereichen der Website. Es sollten während der Entwicklung der Website grundsätzlich eher viele kleine CSS-Dateien angestrebt werden als wenige große. Der CSS-Code wird letztendlich in einer CSS-Datei zusammengefasst und komprimiert an den Browser ausgeliefert.

CSS-Klassen präfixen

Selbstgeschriebene CSS-Klassen können mit einem Präfix versehen werden, damit unmissverständlich ist, woher diese Klassen kommen. Z.B. .kb-header für Kulturbanause Header.

Namenskonventionen verwenden

Es existieren zahlreiche gängige Namenskonventionen, die zur Organisation genutzt werden können – dazu später mehr.

Code kommentieren

Kommentiert euren CSS-Code! Ihr werdet euch selbst dankbar sein, wenn ihr ein älteres Projekt noch einmal öffnet – ganz zu schweigen von euren Kollegen. CSS Präprozessoren wie Sass entfernen Kommentare aus dem Code, so dass sie nicht mehr im Quelltext sichtbar sind.

CSS Code style – den Quelltext formatieren

CSS-Code der an den Browser ausgeliefert wird, sollte komprimiert und möglichst kurz sein. Diese Aufgabe können Tools wie Sass, Grunt, Gulp etc. für uns übernehmen.

Beim Schreiben des CSS-Codes, der von einem menschlichen Entwickler weiterbearbeitet werden soll, steht die Lesbarkeit im Vordergrund. Folgende Regeln haben wir aus unserer Erfahrung mit zahlreichen internen und externen Projekten abgeleitet und halten sie für »gängige Praxis«:

Schreibweise von Selektoren

In CSS ist die Kebap Case-Schreibweise üblich: Mehrere Wörter werden in CSS-Selektoren üblicherweise mit Minus (-) getrennt. Alle Buchstaben werden kleingeschrieben. Aus anderen Sprachen bekannte Schreibweisen wie Camel Case oder Snake Case sind in CSS unüblich.

.meine-klasse {} /* richtig */
.meine_klasse {} /* falsch */
.meineKlasse {} /* falsch */

Einrückung

Verschachtelter CSS-Code – z.B. innerhalb von Selektoren oder @rules sollte eingerückt werden. Üblich ist die Einrückung mit einem Tab. Allerdings gibt es auch für Einrückungen mit vier Leerzeichen Befürworter.

.mein-selektor {
    eigenschaft: wert; /* richtig */
} 

.mein-selektor {
eigenschaft: wert; /* falsch */
}

Umbrüche und Freiräume

Zwischen zwei Selektoren sollte eine Leerzeile stehen. Ein Umbruch sollte nach der öffnenden gewungenen Klammer, sowie hinter jedem Semikolon erfolgen. Wenn mehrere Selektoren mit Komma getrennt hintereinander geschrieben werden, sollte auch hier ein Umbruch nach jedem Komma gesetzt werden. Nach dem Doppelpunkt zwischen Eigenschaft und Wert sollte ein Leerzeichen gesetzt werden.

/* Richtig */
.meine-klasse,
.meine-klasse-2 {
    eigenschaft: wert;
    eigenschaft: wert;
}

/* Falsch */
.meine-klasse, .meine-klasse-2 
{
    eigenschaft:wert;
    eigenschaft:wert;
}

Semikolon hinter letztem Wert

Wenn ein CSS Selektor mehrere Eigenschaft/Werte-Paare beinhaltet, werden diese mit Semikolon getrennt. Das letzte Semikolon kann allerdings weggelassen werden, da keine weitere Eigenschaft folgt. Auch wenn es funktioniert ist es sehr unüblich.

.meine-klasse {
    eigenschaft: wert;
    eigenschaft: wert; /* richtig */
} .meine-klasse {
    eigenschaft: wert;
    eigenschaft: wert /* falsch bzw. unüblich */
}

Eigenschaften thematisch ordnen

Die einzelnen CSS-Eigenschaften innerhalb eines CSS Selektors können thematisch gruppiert werden. Gängig ist eine Gruppierung nach folgenden Bereichen.

1. Schrift
2. Positionierung
3. Display
4. Box-Modell
5. Farben, Hintergründe und weiteres Styling

/* Richtig */
.meine-klasse {
    font-family: Arial;
    position: relative;
    margin: 1em;
    padding: 0.5em;
    background-color: red;
}

/* Falsch */
.meine-klasse {
    padding: 0.5em;
    background-color: red;
    font-family: Arial;
    position: relative;
    margin: 1em;
}

CSS Namenskonventionen

Bei großen Projekten mit erfahrenen Entwicklern, bietet es sich an Namenskonventionen zu nutzen. Die folgenden Konventionen sind am gängigsten:

SMACSS

SMACSS (Gesprochen: »Smacks«) steht für »Scaleable and modern Architektur for CSS«. In erster Linie ist SMACSS eine Sammlung vom Hilfestellungen und Namenskonventionen zur Organisation von CSS-Projekten.

Der CSS-Code wird dabei in folgende Bereiche untergliedert:

• Base
  Elementares Styling von HTML-Elementen.
• Layout
  Unterteilung der Website in grobe Sinnabschnitte wie Header, Footer, Content etc.
• Module
  Wiederverwertbare Bereiche des Layouts – z. B. Boxen, Formulare, Slider etc.
• State
  Zustände von Elementen – z. B. .is-collapsed für Accordions.
• Theme
  Styling für eventuelle Themes, bei multimandantenfähigen Projekten.

Das Konzept kann unter smacss.com eingesehen und in Form eines eBooks kostenlos heruntergeladen werden.

OOCSS

OOCSS steht für objektorientiertes CSS. Bei objektorientiertem CSS werden u.a. Struktur und Aussehen getrennt.

Um eine Infobox zu gestalten würde man in OOCSS beispielsweise nicht die Farbe der Box in der gleichen Klasse definieren wie die Breite und die Höhe. Stattdessen erstellt man zwei CSS-Klassen und kombiniert sie. Somit kann die Gestaltung auch auf andere Objekte angewendet werden. Elemente mit gleicher Struktur und abweichendem Look (z.B. Boxen für Erfolgs- oder Fehlermeldungen) können über weitere visuelle Klassen erzeugt werden.

Üblicherweise werden die Namen thematisch zusammengehöriger Klassen mit dem gleichen Präfix eingeleitet. Z.B. .box, .box-info, .box-error etc.

<section class="box box-info">
  <h3>Zur Info</h3>
  <p>Das ist ein Beispiel</p>
</section>

Ein weiterer wichtiger Bestandteil von OOCSS ist das bewusste Styling über CSS-Klassen. Um die Spezifität gering zu halten, wird wo möglich auf lange Selektoren oder IDs verzichtet.

Solche Selektoren solltet ihr in eurem Code daher nicht finden

#main-menu > ul li.item a { }

Stattdessen vergibt man den Links direkt Klassen und schreibt

.menu-link { }

Mit Hilfe von OOCSS ist möglich es Elemente wiederverwertbar zu machen und den Code schlank zu halten.

BEM

BEM steht für »Block, Element, Modifier« (.block__element--modifier{}) und ist ein Konzept zur Benennung von CSS-Selektoren. Der Vorteil des Konzepts besteht darin, dass Entwickler anhand des Namens die Funktion eines CSS-Selektors erkennen können.

• Der .block stellt die erste und gröbste Abstraktionsebene dar
• An zweiter Stelle steht mit .block__element das Kind-Element des Blocks. Es hilft den .block zu gestalten
• Der .block--modifier wird für Abwandlungen des Blocks verwendet

Anhand zweier Beispiele wird das Prinzip etwas deutlicher:

.sidebar {} /* Block */

.sidebar__box {} /* Element */

.sidebar__box--news {} /* Modifier */

.page-header {} /* Block */

.page-header--fullheight {} /* Modifier */

.page-header__title {} /* Element */

.page-header__subtitle {} /* Element */

.page-header__subtitle-minor {} /* Modifier */

BEM & Sass

Mit einem Präprozessor wie Sass kann die Namenskonvention von BEM sehr unkompliziert eingehalten werden.

.block {
  &__element {
    &--modifier {
      /* Befehle */
    }
  }
}

kompiliert zu

.block__element--modifier {
  /* Befehle */
}

CSS Coding Guidelines

Die oben zusammengefassten Tipps haben wir auf Grundlage unserer Agentur-Erfahrungen zusammengestellt. Insbesondere beim Einsatz von CSS-Namenskonventionen gibt es jedoch häufig keine klare Trennung zwischen den Konzepten. Populär ist eine Mischung aus BEM und OOCSS. So handhaben wir es auch.

Große Unternehmen und Open Source-Projekte haben ihre Coding Guidelines öffentlich zur Verfügung gestellt. Die folgende Liste zeigt einige populäre Beispiele für CSS Goding Guidelines:

• airbnb
• WordPress

Zuletzt möchten wir noch auf das Projekt CSS Guidelines hinweisen. Hier wird die in diesem Beitrag beschriebene Thematik äußerst fundiert beschrieben.

Geschrieben von:

Jonas Hellwig

Jonas ist Gründer der Agentur kulturbanause und des kulturbanause Blogs. Er arbeitet an der Schnittstelle zwischen UX/UI Design, Frontend und Redaktion und hat zahlreiche Fachbücher und Video-Trainings veröffentlicht. Jonas Hellwig ist regelmäßig als Sprecher auf Fachveranstaltungen anzutreffen und unterstützt mit Seminaren und Workshops Agenturen und Unternehmen bei der Planung, der Gestaltung und der technischen Umsetzung von Web-Projekten.

Jonas Hellwig bei Xing