Besserer CSS Code entsteht nicht durch Willenskraft, sondern durch Tools und Konventionen, die dich zwingen, sauberen Code zu schreiben. Mit automatisierten Linting-Tools wie Stylelint, durchdachten Namenskonventionen und einem konsistenten Folder-System sparst du Zeit bei der Wartung und beugst technischer Schuld vor.
Stylelint: Dein automatischer CSS-Qualitätswächter
Bevor du manuell auf Best Practices achtest, kannst du dir einen großen Teil der Arbeit abnehmen lassen. Stylelint ist ein Linter für CSS und SCSS, der dir direkt in VS Code zeigt, wenn du gegen gängige Konventionen verstößt. Du installierst die Extension im VS Code Marketplace, richtest eine Konfigurationsdatei ein, und Stylelint meckert sofort rum, wenn du beispielsweise Farben ausgeschrieben statt als Hex-Code angibst oder Shorthand Properties nicht verwendest.
Das ist kein nettes Extra, sondern eine echte Arbeitserleichterung. Gerade am Anfang lernst du so passiv, was guter CSS-Code bedeutet.
Property Order: Struktur im Selektor
Wenn du CSS-Eigenschaften in deinen Selektoren komplett random anordnest, macht das technisch keinen Unterschied, aber der Code wird schwerer lesbar. Eine bewährte Reihenfolge sieht so aus:
- Positionierung (position, top, left, z-index)
- Display und Box Model (display, width, height, padding, margin, border)
- Typografie (font-family, font-size, color, line-height)
- Alles andere (background, opacity, transitions)
Du kannst das auch auf drei einfache Blöcke runterbrechen: Positionierung, Box Model, Rest. Für kleine Projekte ist das weniger kritisch. Sobald aber mehrere Leute am gleichen Code arbeiten, macht eine einheitliche Struktur das Leben deutlich einfacher. Stylelint lässt sich so konfigurieren, dass es bei falscher Reihenfolge direkt einen Fehler wirft.
Shorthand Properties und Farben richtig schreiben
Statt vier Zeilen für Padding zu schreiben, fasst du es zusammen:
/* Nicht so */
padding-top: 10px;
padding-right: 15px;
padding-bottom: 10px;
padding-left: 15px;
/* So */
padding: 10px 15px;
Das gilt für padding, margin, border und background. Bei Farben gilt dasselbe Prinzip: Schreib sie nie als Klarnamen (white, red), sondern als Hex-Code. Wenn alle sechs Zeichen identisch sind, kürzt du weiter ab: #ffffff wird zu #fff.
Noch sauberer ist es, alle Farben als CSS-Variablen zu definieren:
:root {
--color-primary: #00dcff;
--color-background: #141414;
}
Dann änderst du eine Farbe an einer einzigen Stelle und musst nicht durch den gesamten Code suchen.
CSS-Spezifität: Die Regel hinter den Regeln
Das ist das Thema, das am häufigsten zu Kopfschmerzen führt, wenn man es nicht versteht. Spezifität bestimmt, welcher Selektor gewinnt, wenn mehrere Selektoren dasselbe Element ansprechen.
Die Logik funktioniert so:
- IDs (
#mein-element) haben die höchste Spezifität (100) - Klassen, Attribute, Pseudoklassen (
.meine-klasse,:hover) haben mittlere Spezifität (10) - Elemente (
div,li) haben die niedrigste Spezifität (1)
Die goldene Regel: Spezifität immer so niedrig wie möglich halten. Konkret bedeutet das: Selektiere fast immer nur über Klassen. Vermeide Kombinationen wie li.item, weil du damit unnötig Spezifität aufbaust. Wenn .item reicht, nimm .item.
Warum Inline Styles und !important gefährlich sind
Inline Styles (style="background: red;") überschreiben alle externen Stylesheets. !important überschreibt sogar Inline Styles. Beide führen in eine Abwärtsspirale: Du baust immer aggressivere Selektoren, nur um frühere Fehler zu korrigieren. In einem professionellen Team werden dir Senior-Entwickler im Code Review direkt erklären, warum das nicht geht. Besser von Anfang an saubere Klassen verwenden.
BEM: Klassennamen die Sinn ergeben
BEM steht für Block, Element, Modifier. Es ist eine Methode, wie man Klassennamen so benennt, dass sie sofort verständlich sind und die Spezifität niedrig bleibt.
Ein Beispiel mit einer Navigationsleiste:
.nav-bar {
} /* Block */
.nav-bar__item {
} /* Element */
.nav-bar__item--active {
} /* Modifier */
Im HTML weist du dem aktiven Element beide Klassen zu: class="nav-bar__item nav-bar__item--active". Der Vorteil: Jeder Selektor hat genau eine Klasse, also immer Spezifität 10. Kein Chaos durch verschachtelte IDs oder Element-Selektoren.
In SCSS kannst du BEM besonders komfortabel mit Nesting schreiben:
.nav-bar {
&__item {
color: white;
&--active {
text-decoration: underline;
}
}
}
Solche Patterns lernst du im Fullstack Web Developer Kurs von DevKarriere von Grund auf, mit echten Projekten und direktem Feedback.
Häufige Fragen
Muss ich BEM verwenden oder gibt es Alternativen?
BEM ist eine Empfehlung, keine Pflicht. Es gibt andere Methoden wie SMACSS oder OOCSS. Wichtig ist nur, dass du konsequent eine Methode anwendest. Wer Tailwind CSS verwendet, braucht BEM oft gar nicht, weil Utility-Klassen das Problem anders lösen.
Wann ist !important doch okay?
Es gibt legitime Ausnahmen: Wenn du CSS von Drittanbietern überschreiben musst und keinen anderen Weg hast, oder in sehr spezifischen Utility-Klassen die immer gelten sollen (.hidden { display: none !important; }). Als Faustregel gilt trotzdem: Wenn du !important brauchst, um eigenes CSS zu überschreiben, stimmt etwas mit deiner Selektorstruktur nicht.
Wie prüfe ich, ob ein CSS-Feature in allen Browsern funktioniert?
Mit caniuse.com siehst du für jede CSS-Property, welche Browser-Versionen sie unterstützen. Besonders nützlich, wenn du beispielsweise die gap-Property in Flexbox verwendest, die ältere iOS-Safari-Versionen nicht vollständig unterstützen. Für die meisten modernen Projekte ist das kein Problem, aber es lohnt sich, einen Blick drauf zu werfen.