Vielleicht reicht die Grafik aus, um die Botschaft dieses Beitrags vorwegzunehmen. Es geht hier nicht um die technische Umsetzung an sich, sondern darum, wie man CSS schreibt.
Wie bei jeder Handschrift hat auch bei CSS jeder einen andern Stil und individuelle Vorlieben. Nichtsdestotrotz bereitet eine »Sauklaue« einer Handschrift den meisten Menschen Probleme beim Lesen - im Gegensatz zu einer fein säuberlichen Schrift.
Nicht anders ist es im CSS. Schreiben von CSS bedeutet nicht einfach nur, dass man maschinenbrauchbaren Code herstellt. Computer beziehungsweise Browser lesen lediglich die Bits & Bytes. Wie diese im Quelltext stehen ist vollkommen unbedeutend.
CSS schreiben bedeutet immer, dass man einen Code auch lesen können muss. Dies ist vor allem wichtig, wenn Sie im Team arbeiten, und die Kollegen verstehen sollen, was Sie sich gedacht haben. Aber auch Sie selbst sind Ihr eigener Teamplayer. Frontendentwicklung bedeutet im Alltag, dass Quelltexte nie final sind, sondern über lange Strecken immer wieder bearbeitet werden. Sei es, weil Sie die Seite erweitern, sei es, dass ein Kunde neue Features haben möchte.
Die Bearbeitung eines CSS-Codes passiert nicht immer innerhalb von zwei Wochen, wo Sie mit dem Kopf noch mitten drin stecken. Manchmal vergehen Jahre, wenn Sie eine CSS-Datei erneut öffnen. Sie werden sich selber dankbar sein, wenn Sie zuvor »ordentlich« gearbeitet haben.
Browserintern ist es gleich, wie viele Leerzeichen und Zeilenumbrüche in einer CSS-Datei sind, Browser »schmeißen« diese beim Einlesen ohnehin raus. Die Freiheit, Leerzeichen beliebig setzen zu dürfen, können Sie nutzen, um gut leserliches CSS zu schreiben.
Browser erkennen eine solche Codezeile, 50 solcher Zeilen werden jedoch Entwickler vor ein Rätsel stellen. Ein »menschenlesbarer« Code sollte immer das Ziel sein.
Welche Art der Einrückung und Leerzeichen Sie wählen, ist letztendlich Geschmacksache. Ein paar Anregungen möchte ich jedoch formulieren:
:
(Doppelpunkt) unterstützt
zusätzlich die Lesbarkeit;
(Semikolon) ab, auch
wenn die letzte Deklaration keins benötigt. Dies verschafft
Übersichtlichkeit durch Einheitlichkeit, vermeidet vor allem Fehler,
wenn Sie nachträglich noch eine Deklaration hinzufügenWer es mag, kann zusätzlich die einzelnen Werte auf eine einheitliche Höhe rücken.
Hiermit schaffen Sie ein Optimum an Ordnung. Diese Schreibweise hat allerdings den Nachteil, dass die Einrückung von der längsten Eigenschaft abhängt. Falls Sie später eine längere Eigenschaft hinzufügen, sind Sie damit beschäftig, viele Leerzeichen »nachzuarbeiten«, was bei komplexen Regeln recht aufwendig werden kann. Da hier viel Zeit vertan werden kann, halte ich Einrückungen der Werte auf die gleiche Höhe für wenig praktikabel, die zuvor gezeigte Struktur ist in der Praxis üblich und ausreichen. Aber auch hier gilt: Es ist Geschmacksache!
Nicht nur eine leserliche Datei, sondern auch die Wahl der Bezeichner für
class
und id
sollten stets gut gewählt werden.
Namen wie .type-2
oder .level_3Box
lassen weder
darauf schließen, in welchem Kontext etwas zu finden ist, noch welche
Funktion damit verbunden ist..hinweis
oder .link-aktiv
sind sicher bessere Klassennamen.
Auch die id
-Bezeichnungen #kopf
,
#inhalt
oder #fuss
sind brauchbare Namen. Hier
kann man auch englische Entsprechungen wählen, umso einfacher Sie die Namen
aber wählen, umso effektiver werden Sie selber und Kollegen mit den
Quelltexten arbeiten können.
Die Wahl der Bezeichner, die Benennung von Dateinamen oder Grafiken sollte stets nach dem KISS-Prinzip geschehen: »Halte es so einfach wie möglich«. In einem wirklich guten Quellcode – und das gilt letztendlich für alle Programmiersprachen – sind alle Bezeichnungen so gewählt, dass Entwickler, die drauf schauen, diese sofort verstehen. Ganz nebenbei: Eine intuitive Struktur und sprechende Benennung aller Selektoren erspart Ihnen eine aufwendige Dokumentation.
Gleiches gilt für die Benennung von Dateien. Eine Haupt-CSS-Datei sollte style.css, design.css oder layout.css heißten. Lagern Sie beispielsweise CSS Formulare aus, benennen Sie die Datei auch so. extension.css lassen keine Schlüsse auf den Inhalt schließen, formulare.css hingegen schon.