Jul 21

Ich habe während meiner Hobby- und Berufslaufbahn nun schon die ein oder andere Webseite erstellt und auch Code von noch viel mehr (fremden) Webseiten angeschaut. Ein Sonderfall der dabei auftritt ist der, dass ich eine bereits existierende Webseite verändern oder erweitern soll. Dabei denkt man als Entwickler meist: schön, die meiste Arbeit ist bereits getan! Meist trifft das leider nicht zu. Vielmehr handelt es sich bei den bereitgestellten „lauffähigen“, lassen wir es uns „Dingen“ nennen, um ein großes Kartenhaus welches nach ersten Kontakten in sich zusammenstürzt.

Nun sitzt man meist vor der Entscheidung alles neu zu schreiben oder den vor einem liegenden Haufen aufzuräumen. Aus Kostengründen wird einem als Entwickler ab und an die Entscheidung von höherer Ebene abgenommen – neu bauen ist zu teuer. Das auch diese Einschätzung in den meisten Fällen eine Milchmädchenrechnung ist, weiß der geneigte Entwicklerkollege sicher nur allzugut.

Aber egal ob „hinter dem Rücken“ oder ganz offiziell, wir schreiben meist alles neu. Doch was sind die Gründe dafür? Ich möchte diese Frage in diesem Artikel auf CSS-Dateien beschränken und setze das vielleicht später mit HTML und PHP fort. Deshalb also jetzt meine Schlussfolgerungen aus 5 Jahren Webentwicklung.

Das Problem der meisten CSS-Files ist zu allererst die Form. Wie man Selektoren und Attribute sortiert, kann jedoch bereits überall nachgelesen werden (Beispiel). Im Idealfall hat die Firma für die man arbeitet (oder man selbst als Freelancer) jedoch einen Styleguide oder eine Coding-Guideline für diesen Zweck. Gehen wir also davon aus, dass die Form stimmt und auch die „richtigen“ Styles benutzt wurden (Es mag anfangs seltsam erscheinen, aber im IE6 sollte man z.B. auf Paddings verzichten). Damit legen wir den Grundstein für eine CSS-Datei die auch später noch pflegbar ist – vor allem für andere Entwickler. Und gerade das wird in Teams leider oft unterschätzt.

Doch weiter zum eigentlichen Kern der Sache: der Semantik. Da wird bei HTML in den wenigsten Fällen noch diskutiert und die meisten Entwickler beschwören gemeinsam valides und semantisch sinnvolles Markup, da „passieren“ bei CSS die gleichen Fehler wie noch vor fünf Jahren.

Ein Beispiel: Auf der potentiellen Kundenwebseite gibt verschiedene Elemente die den gleichen Zweck haben. Das könnten verschiedene Teaser am Rand der Seite sein oder auch verschiedene Buttons die überall auf der Webseite den gleichen Zweck erfüllen (Hilfe-Fenster, speichern, usw.). Diese Elemente befinden sich im Code allerdings an völlig unterschiedlichen Stellen. Die möglichen Lösungen:

  1. Wir picken uns ein Element heraus body>div#container>div.teaser und beschreiben es mit CSS (Breite, Hintergrund, Schriftgröße). Genau unter unserem Element befindet sich nun ein anderes Element aus der Gruppe 1, z.B. eine Loginbox. Sie hat die gleiche Breite und Schriftgröße wie das erste Element. Dazu kommt allerdings eine andere Hintergrundfarbe. Da sich mindestens eine Eigenschaft unterscheidet, schreiben wir einen neuen Selektor (body>div#container>div#loginbox) und kopieren die Styles vom Teaser. Dann ändern wir lediglich den Hintergrund und fertig. Dazu kommt nun ein Eingabefeld im Kontaktformular welches zufällig genauso formatiert werden soll, wie es einer unserer Selektoren beschreibt. Lösung: wir schreiben einen weiteren Selektor an die Stylegruppe:

    div.teaser {
    background-color: #ddd;
    font-size: 85%;
    width: 200px;
    }
    div#loginbox, input.gray {
    background-color: #ccc;
    font-size: 85%;
    width: 200px;
    }

    Das Problem dabei ist folgendes: Ändert sich im Design ein einzelner Wert (z.B. die Breite), dann muss im CSS an mehreren Stellen angepasst werden. Gehen nun noch davon aus, dass unsere CSS-Datei 1000 Zeilen hat und etwas komplexer ist als mein Beispiel, dann hat man für eine simple Änderung schon ziemlich viel zu tun. Dazu kommt: wenn sich nur die Breite der Extracontainer ändert, das Eingabefeld aber nicht, dann müssen wir sogar das CSS umbauen. (meist wird dafür die einzelne Eigenschaft dann weiter unten noch überschrieben)

  2. Das ist der „so-wie-es-sein-sollte“-Fall. Wenn Elemente sich aus semantischen Gründen die gleichen Eigenschaften teilen, dann gehören eben diese Eigenschaften in eine Gruppe mit den beiden Selektoren. Hat ein anderes Element zufällig die gleichen Eigenschaften, gehört nicht mit dort hinein. Das obige Beispiel sähe also so aus:

    div.teaser, div#loginbox {
    font-size: 85%;
    width: 200px;
    }
    div#loginbox {
    background-color: #ccc;
    }
    div.teaser {
    background-color: #ddd;
    }
    input.gray {
    background-color: #ccc;
    font-size: 85%;
    width: 200px;
    }

    Das hat nun den Vorteil, dass man die sich ändernen Werte tatsächlich nur an einer Stelle beachten muss. Ändert sich die Breite der Spalte, so betrifft das den oberen Selektor, denn dort wird sie für alle Elemente dieser semantischen Gruppe festgelegt. Ändert sich jedoch die Farbe einer Box, kann dies ebenfalls an nur einer Stelle geändert werden.

Damit das so funktioniert, muss natürlich allen im Team die Sematik der Webseite klar sein. Wenn also die Teaser von Enwickler 1, der Login von Entwickler 2 und das Kontaktformular von Entwickler 3 umgesetzt werden, wissen die natürlich erstmal nichts davon und suchen sich bestenfalls einen passenden Style der schon exisitert (so geschehen für das Eingabefeld im Beispiel 1) und wundern sich später, warum es plötzlich „falsch“ aussieht, nachdem Entwickler 2 seine Loginbox modifiziert hat. Hier ist also ein allgemeines Verständnis der Webseite als Ganzes sowie Kommunikation im Team gefragt.

Weit verbreitet ist die falsche Benutzung übrigens bei Größenangaben von Elementen die auf der Webseite unter- oder nebeneinander platziert werden sollen. Wenn sie anderen Inhalt haben, wird meist jedes Element einzeln beschrieben. Wesentlich mehr Sinn würde jedoch die Gruppierung einzelner Eigenschaften bringen. Natürlich wieder nur, wenn sie semantisch zusammengehören und nicht nur zufällig.

Obwohl der Inhalt ziemlich theoretisch ist, habe ich mit dem Beispiel hoffentlich klar machen können worum es im Kern geht. Ich freue mich über Kommentare, also immer her damit! Für Optimierungs-Fanatiker jedoch gleich vorweg: Ich bin mir durchaus bewusst, dass die CSS-Datei dadurch bis zu 20% größer werden kann, jedoch kann ich aus Erfahrung sagen, dass das bisher noch nie ein Problem war und mir die Vorteile sehr viel Arbeitszeit und Nerven gespart haben…

Einen Kommentar schreiben