Wenn Code schlecht wird, Teil 2 – valides CSS schreiben

Als Webentwickler verwenden Sie wesentlich mehr Zeit darauf, den Code anderer Leute aufzuräumen oder sich mit den Folgen unglücklicher Designs herumzuschlagen, anstatt selbst zu programmieren und das Leben der Anwender leichter zu machen. Wie Sie vermeiden, dass andere Leute sich später über Ihren Code ärgern, ist Thema dieser Artikelserie – Teil 2 legt den Fokus auf CSS.

CSS

Manche Menschen haben einen komischen Umgang mit CSS. Jahrelang haben wir uns über fehlende oder sporadische Browser-Unterstützung für CSS beklagt. Zudem gab es wenig Unterstützung von anderen Entwicklern, da viele CSS als nicht einsetzbar links liegen ließen und sich heute noch immer nach dem Komfort „leicht anwendbarer Layout-Tabellen“ zurück sehnen. CSS hat es dennoch geschafft und das ist gut so, da CSS Aussehen und Dokumentenstruktur trennt, so dass auf der kompletten Website mit tausenden von Dokumenten bestimmte Einstellungen schnell und bequem geändert werden können.

CSS ist recht einfach zu erlernen – die Syntax ist geradezu lächerlich simpel. Trotzdem können manche Leute einfach nicht begreifen, dass CSS dazu gedacht ist, andere Webtechnologien zu ergänzen – ein Ersatz ist es nicht.

Eine Reihe „reiner CSS-Lösungen“ ist unter bestimmten Gesichtspunkten unbefriedigend – etwa der Zugang über die Tastatur, Zugang per Touchscreen (ich kann zum Beispiel kein Hover-Menü auf meinem Smartphone verwenden) sowie die allgemeine Kontrolle Ihrer Aktionen. CSS ist eine Art Einzelanfertigung. Sie wenden es an und hoffen, dass alles gut geht. Mit JavaScript können Sie wirklich testen, ob alles so gerendert wird, wie Sie sich das gedacht haben. Zudem können Sie prüfen, ob es genug Platz für einen bestimmten Effekt gibt, bevor Sie diesen einsetzen. CSS geht mit media queries und den CSS3-Eigenschaften animation und transform in eine ähnliche Richtung. Letztendlich ist das jedoch ein Versuch, JavaScript zu simulieren. Indem Sie eine gute JavaScript-Bibliothek und ein wenig CSS verwenden, können Sie all diese Effekte schon jetzt browserübergreifend erreichen.

Ursachen und mögliche Lösungen

Wenn CSS-Code „schlecht“ wird, lässt sich das in der Regel auf diese Punkte zurückführen:

• Browser-Standardeinstellungen sind erlaubt
• Die Syntax ist übermäßig verschachtelt
• CSS wird ohne vorherige Analyse zugefügt
• Der Code ist zu spezifisch
• Verwendung Browser-spezifischer Hacks und -technologien

Schauen wir uns das wiederum im Einzelnen an.

Erlauben von Browser-Standardeinstellungen

Seiten ohne Stilvorlagen gibt es nicht, da Browser vordefinierte Stile haben, nach denen ein HTML-Dokument dargestellt wird. Das Problem daran: Jeder Browser hat andere Stilvorgaben. Wenn Sie ein bestimmtes Aussehen und Verhalten erreichen wollen, sind Sie gezwungen, alle möglichen Einstellungen zu überschreiben, die vom Browser automatisch voreingestellt wurden.

Um dieses Problem zu umgehen, verwenden Sie am besten eine CSS-Reset-Datei oder – um es ganz einfach zu machen – eine einzige Codezeile:

*{margin:0;padding:0}

Damit überschreiben Sie sämtliche Vorgaben für Rand und Padding, die der Browser auf Elemente anwendet. Wenn Sie etwas Raffinierteres benötigen, können Sie mit einem Reset-Stylesheet arbeiten, zum Beispiel mit diesem hier: Yahoo User Interface CSS Reset. Sie können sogar sämtliche Browser-Vorgaben für Schriftgrößen aushebeln, indem Sie die Datei fonts.css verwenden.

Mit einem CSS-Reset können Sie nicht nur die Standardeinstellungen des Browsers los werden. Es bedeutet, dass Sie wirklich mit einem „unbeschriebenen Blatt“ starten und Ihr eigenes Aussehen definieren können, ohne dass Sie Margin oder Padding einstellen müssen, wo es gar nicht nötig ist.

Die Syntax ist übermäßig verschachtelt

CSS hat ganz hervorragende Kurznotationen, mit denen Sie Ihren Code schlank und einfach halten können.  Es hat zudem den angenehmen Nebeneffekt, dass man nicht nach bestimmten Einstellungen fahnden muss. Wenn Sie also eine bestimmte Eigenschaft für Ihr Design festlegen, tun Sie das gebündelt, an einem Ort, anstatt den Code aufzusplitten – etwa so zum Beispiel:

#pagetitle{
 color:black;
  text-align:left;
  border-top-width:2px;
  border-top-color:black;
  padding-left:2em;
  border-right-color:white;
  border-left-width:2px;
  border-top-style:solid;
  border-left-color:black;
  border-bottom-width:2px;
  line-height:1.3em;
  position:absolute;
  border-right-style:solid;
  right:0;
  padding-right:2em;
  padding-bottom:1em;
  width:30em;
  border-bottom-style:solid;
  border-bottom-color:white;
  top:10em;
  border-left-style:solid;
  padding-top:1em;
  height:3em;
  border-right-width:2px;
}

Einen Code wie diesen zu pflegen kann ganz schön mühsam sein – Einstellungen für border sind überall verstreut. Zudem ist der Code unnötig aufgebläht. Das Gleiche gilt für die Positionierung und Abmessungen der Box. Wenn Sie die Eigenschaften logisch ordnen und die Kurznotation verwenden, können Sie den Code erheblich vereinfachen. In diesem Fall gilt die Grundregel, eine einheitliche Voreinstellung festzulegen und nur dort, wo es Abweichungen davon gibt, die Voreinstellung zu überschreiben – nämlich so:

#pagetitle{
  color:black;
  text-align:left;
  line-height:1.3em;

  border:2px solid white;
  border-color:black white white black;

  padding:1em 2em;
  position:absolute;
  top:10em;
  right:0;
  width:30em;
  height:3em;
}

Auf diese Weise haben wir einen durchgezogenen, weißen Rand für die gesamte Box eingestellt und anschließend nochmals die Farben für den Rand für die einzelnen Seiten festgelegt – denn das ist das Einzige, was sich ändert. Die Farben werden im Uhrzeigersinn, angefangen von oben definiert – sprich: top, right bottom, left. Das Gleiche gilt fürs Padding: Wenn Sie jeweils dieselben Werte für links und rechts beziehungsweise oben und unten haben, können Sie das abkürzen mit je einer Angeabe für left / right und top / bottom. Wenn Sie dann noch die Einstellungen nach Schriftart, Rand, Position und Abmessungen ordnen, machen Sie es Dritten und sich selbst einfach, sich in Ihrem Code zurecht zu finden, wenn Sie später etwas ändern müssen.

Das können Sie übrigens auch erreichen, indem Sie gemeinsame Denominatoren festlegen und diese aus den spezifischen Selektoren auslagern, um beispielsweise die gemeinsamen Einstellungen aller Überschriften zusammen zu fassen. Hier ein Beispiel, wie man es nicht machen sollte:

h1{
  font-family:helvetica,arial,"lucida sans",sans-serif;
  color:#000;
  margin:.5em 0;
  padding:1em;
  font-size:150%;
  background:#ccc;
}
h2{
  font-family:helvetica,arial,"lucida sans",sans-serif;
  color:#000;
  font-size:120%;
  margin:.5em 0;
  padding:1em;
  background:#999;
}
h3{
  font-family:helvetica,arial,"lucida sans",sans-serif;
  color:#000;
  margin:.5em 0;
  font-size:110%;
  padding:1em;
  background:#666;
}
h4{
  font-family:helvetica,arial,"lucida sans",sans-serif;
  color:#000;
  margin:.5em 0;
  font-size:105%;
  padding:0;
}

Im obigen Beispiel sind viele Angaben redundant. Legen Sie am Anfang einmal das fest, was für alle Elemente gleich ist und notieren Sie danach nur noch die Abweichungen:

h1,h2,h3,h4,h5,h6{
  font-family:helvetica,arial,"lucida sans",sans-serif;
  color:#000;
  margin:.5em 0;
  padding:1em;
}
h1{
  font-size:150%;
  background:#ccc;
}
h2{
  font-size:120%;
  background:#999;
}
h3{
  font-size:110%;
  background:#666;
}
h4{
  font-size:105%;
  padding:0;
  background:transparent;
}

So können Sie die grundlegenden Einstellungen für alle Überschriften an einem Ort ändern. Beachten Sie, dass die Standardeinstellung für h4 überschrieben werden muss, da h4 weder einen Hintergrund noch Padding hat.

Wenn Sie Ihr CSS analysieren, finden Sie zahlreiche Möglichkeiten, es zu verkürzen und damit pflegeleichter zu machen.

CSS ohne vorherige Analyse hinzufügen

Sperriger und schwer zu pflegender CSS-Code entsteht vor allem dadurch, dass viele Autoren es an vorhergehender Analyse fehlen lassen. Anstatt den Code durchzusehen und an einer geeigneten Stelle eine Definition durch eine Änderung zu überschreiben, wird einfach zusätzlicher Code am Ende des Stylesheets eingefügt. So finden Sie am Ende von Stylesheets zum Beispiel häufig Angabe wie diese:

#main #content .entry p span{color:#999;}
#nav ul li.entry a.sitelink span.current{font-family:arial;}

Es kann sehr entmutigend sein, eine CSS-Datei für die erforderliche nach dieser einen Einstellung zu durchsuchen und anschließend zu prüfen, was passiert, wenn Sie die Einstellung ändern. Je komplexer und voluminöser eine Website ist, desto abschreckender erscheint die Aufgabe. Es könnte sein, dass Sie einen scheinbar redundanten Selektor finden und löschen, nur um dann festzustellen, dass er an einer anderen Stelle durchaus eine tragende Rolle spielte.

Wenn Sie neue Browser Debugging Tools wie Firebug oder Webentwicklungs-Tools verwenden, können Sie jedoch die Stilvorgaben bestimmter Elemente einer Seite und woher die darauf angewandten Stile kommen, so dass Sie die entsprechenden Angaben an der Quelle ändern können. Darüber hinaus gibt es Tools, mit denen Sie verwaiste CSS-Einstellungen, die gelöscht werden sollten, aufspüren können. Es kann natürlich sein, dass Sie unsicher über die Bedeutung und den Zusammenhang dieser Einstellungen sind, so dass Sie lieber einen sehr spezifischen Selektor einfügen, um das Problem zu lösen. Wenn Sie mit mehreren Personen den Code pflegen, lösen Sie mit diesem Vorgehen jedoch ein Rennen aus, das Sie nicht gewinnen können. Und zu allem Übel blasen Sie Ihren Code unnötig auf.

Der Code ist zu spezifisch

Ein ähnlicher Wettkampf beginnt, wenn Sie zu spezifische Selektoren verwenden. Spezifität bedeutet, dass ein bestimmter Selektor definiert, welche Stile auf ein Element angewendet werden. Wenn Sie also für dasselbe Dokument einmal p{color:#000;} und einmal #main p{color:#ccc;} notieren, werden alle Abschnitte im Element mit der ID #main hellgrau sein, nicht schwarz, weil der #main-Selektor die Vorgabe spezifischer macht.

Die Folge: Jedesmal wenn eine mit der Pflege des Codes betraute Person, ein so genannter Maintainer, einen neuen Stil hinzufügen möchte, muss zusätzlich zum Selektor obendrein ein weiteres Element eingefügt werden – eine Klasse oder eine ID, um das neue Aussehen realisieren zu können. Um das Leben der anderen einfacher zu machen, sollten Sie versuchen, die Spezifität Ihrer Selektoren möglichst gering zu halten. Überlassen Sie die Definition der „krummen Kandidaten“ den späteren Hütern des Codes. Auf diese Weise unterstützen Sie die Wiederverwendung von Selektoren. Ein div.warning{color:#c00;background:#fcc} lässt sich nur auf DIVs anwenden, während ein Maintainer die Klasse warning auch einem Listenelement zuweisen könnte, wenn Sie stattdessen lediglich .warning{color:#c00;background:#fcc} definiert hätten.

Browserspezifische Hacks und Technologien verwenden

Nur weil gerade etwas cool ist und sehr beeindruckend aussieht, ist es noch lange nicht reif für den flächendeckenden Einsatz noch dass es in einem Jahr noch immer cool ist. IE6 hat eine atemberaubende Anzahl herstellerspezifischer CSS-Erweiterungen als es neu herauskam. So konnten Sie beispielsweise bereits 1999 HTML-Inhalte mithilfe eines IE-spezifischen Filters rotieren. Zur Zeit macht Webkit/Chrome dasselbe.

Es gibt eine ganze Reihe cooler CSS-Tricks, die auf einem iPad oder iPhone sehr beeindruckend aussehen. Auf anderen Browsern als Safari laufen sie jedoch nicht; zudem sind sie auf sehr langsamen Computern eher störend als hilfreich. Bevor Sie sich von den Möglichkeiten eines geschlossenen Systems begeistern lassen und behaupten, dies sei das Web, unternehmen Sie ein paar Tests außerhalb Ihrer Komfortzone und wenden Sie die neuen Möglichkeiten nur dann an, wenn sie außerhalb dieser Zone funktionieren.

Stichwort Wartung – es könnte eine gute Idee sein, browserspezifische Vorgaben am Ende einer Einstellung zu notieren statt quer im Code. Ein Beispiel:

#message{
  width:90%;
  padding:.5em;
  font-size:110%;
  font-weight:bold;
  border:2px solid #000;
  border-radius:10px;

  /* Firefox */
  -moz-border-radius:10px;
  -moz-box-shadow:4px 4px 4px rgba(33,33,33,.4);

  /* Safari / Chrome */
  -webkit-border-radius:10px;
}

Diese Schreibweise macht es einfach, herstellerspezifische Regeln später zu entfernen, wenn einst alle Browser die Standards unterstützen und das Standard-Konsortium sich schon bald darauf geeinigt hat, was Standard sein wird und was nicht (und wenn Schweine dereinst fliegen können).