XHTML- und CSS-Code-Richtlinien bei GMX

Artikel vom 26. März 2006 (↻ 1. Januar 2016). ISSN 1614-3124, #21. Schwerpunkt:  (RSS-Feed).

Dieser Artikel kann seit August 2006 inhaltlich nicht mehr aktualisiert werden. Wer einen guten Überblick zum Thema Code-Richtlinien will, mag sich mein kleines Buch zum Thema ansehen: The Little Book of HTML/CSS Coding Guidelines.

Code-Richtlinien oder »Coding Guidelines« sind notwendig und hilfreich, um einheitlichen, übersichtlichen Code zu gewährleisten und dadurch effektiver zu arbeiten. Sie sind um so wertvoller, je mehr Leute am Quelltext von Dateien arbeiten. Die vorliegenden Richtlinien für XHTML und CSS werden beim Kommunikationsdienst GMX bereits seit 2004 erfolgreich angewendet.

Für diese Veröffentlichung wurden alle Richtlinien nochmal leicht überarbeitet, sie stellen ansonsten aber den Stand vom Januar 2005 dar. Interessierte mögen sie einfach übernehmen oder den eigenen Vorstellungen und Erfordernissen angleichen und einsetzen. Leider legen auch heutzutage nur die wenigsten Entwickler und Unternehmen Wert auf einheitlichen HTML- und CSS-Code – und profitieren somit auch nicht davon.

Ebenso wie das online sichtbare GMX-Markup Einflüssen des dahinterliegenden CMS unterliegt, wurden die online stehenden GMX-Stylesheets komprimiert, um Ladezeit einzusparen. Sie brechen also nur scheinbar die vorgestellten Richtlinien.

Neben den Code-Richtlinien legen auch einige der hier nicht näher erläuterten CSS-Designprinzipien bei GMX großen Wert auf Wartbarkeit und Übersicht. Dieser Fokus kollidiert aber besonders bei großen und vielschichtigen Informationsangeboten mit dem Ziel, Stylesheets möglichst effektiv und schlank zu gestalten (alle GMX-Stylesheets zusammen umfassen etwa 2.000 Deklarationen). Organisation und Aufbau von Code ist aber das eine, wie man ihn schreibt, das andere.

Inhalt

  1. XHTML
    1. Einleitung
    2. Beispiel
    3. Richtlinien
      1. Einrückung
      2. Doppelte anstatt einfache Anführungszeichen
    4. Namensgebung
  2. CSS
    1. Einleitung
    2. Beispiel
    3. Richtlinien
      1. Einrückung
      2. Klammersetzung
      3. Leerzeichen zwischen Eigenschaft und Wert
      4. Semikolon hinter jeder Deklaration
      5. Alphabetische Sortierung von Deklarationen
      6. Verwendung von Kurzschrift-Eigenschaften
      7. Werte
      8. Referenzierung
    4. Selektorenreihenfolge
    5. Kommentare
  3. Nachtrag (21. Dezember 2006)

XHTML

Einleitung

Auf der Oberfläche von GMX wird durchgängig XHTML in Form von XHTML 1.0 Transitional verwendet, und Kenntnis dieses Dokumenttyps wird vorausgesetzt. Besondere Aufmerksamkeit sollte der grundsätzlich möglichst problemlosen Umstellung auf XHTML 1.1 gelten, da dieser Dokumenttyp nur aufgrund vor allem von Werbepartnern verwendeten iframe-Elementen sowie des zugestandenen Gebrauchs von target-Attributen (noch) nicht verwendet wird.

Zwei besondere Ansprüche charakterisieren bei GMX die Arbeit mit HTML-Dokumenten: Das HTML soll valid und semantisch sein – dies erfordert neben der Validierung erstellter Dokumente (über den W3C-Validierer und alternative Werkzeuge) zudem kontinuierliche Code-Reviews, um unter anderem die Semantik des erstellten Codes zu gewährleisten.

Beispiel

Generelles, beispielhaftes XHTML-Dokument:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "https//www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Sample page</title>
    <meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
    <link rel="stylesheet" type="text/css" href="default.css" />
  </head>
  <body>
    <h1>Section Title</h1>
    <p>Sample text.</p>
    <p class="note">A note.</p>
    <p id="footer">Page footer including copyright note.</p>
  </body>
</html>

Richtlinien

Einrückung

Block-Elemente erfordern immer eine neue Zeile, und sie werden um eine Tabulatorlänge eingerückt (Ausnahme: Root-Element). Sofern sie keine weiteren Block-Elemente beinhalten, wird das entsprechende Element auch in derselben Zeile wieder geschlossen. Listenelemente werden ebenfalls eingerückt, wie auch bei Tabellen jedes Element (zum Beispiel caption, thead, tbody, tfoot, tr, th, td) in einer einzelnen Zeile steht und gegenüber dem Elternelement eingerückt wird.

Beispiel für eine Tabelle:

<table>
  <caption>Table caption</caption>
  <thead>
    <tr>
      <th scope="col">Column 1</th>
      <th scope="col">Column 2</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Sample text</td>
      <td>Sample text</td>
    </tr>
  </tbody>
</table>

Beispiel für eine Liste:

<ul>
  <li>Sample text</li>
  <li>Sample text
    <ul>
      <li>Sample text</li>
      <li>Sample text</li>
      <li>Sample text</li>
    </ul>
  </li>
  <li>Sample text</li>
</ul>
Doppelte anstatt einfache Anführungszeichen
Falsch:
<p class='note' />
Richtig:
<p class="note" />

Namensgebung

Dieser Punkt betrifft die Wahl von geeigneten ID- und Klassennamen und somit sowohl Markup als auch Stylesheets. Namen sind grundsätzlich so zu vergeben, dass sie entweder generisch sind oder die Funktion des betroffenen Elements wiedergeben – nicht seine Formatierung. Bei Fehlermeldungen beispielsweise ist red ein unzureichender Klassenname, während error hingegen eine gute Wahl darstellt.

Falsch:
<p class="yellowBorder" />
Richtig:
<p class="warning" />

… aber (Stichwort Semantik):

Falsch:
<span class="headline">Überschrift</span>
Richtig:
<h1>Überschrift</h1>

Idealerweise erfolgt der Gebrauch von IDs und Klassen spartanisch – oftmals reicht es, über den Elementkontext vorzugehen, was einem eher aufwendige und vielleicht einfach unnötige Markup-Änderungen erspart.

Besteht eine ID oder Klasse aus mehreren »Einheiten«, sind diese über einen Gedankenstrich zu trennen:

Falsch:
<ul id="nav2" />
Richtig:
<ul id="nav-2" />

CSS

Einleitung

Die CSS-Code-Richtlinien umfassen strikte Regeln zur Formatierung, die alle bei GMX erstellten und gewarteten Stylesheets betreffen. Die Code-Richtlinien dienen zum einen der Vereinheitlichung des Quelltextes, zum anderen tragen sie dafür Sorge, dass ein gewisses Maß an Übersichtlichkeit gewährleistet wird (zum Beispiel durch Einrückung von CSS-Regeln oder alphabetische Sortierung).

Vorangetrieben und unterstützt wird diese Praxis durch sogenannte Code-Reviews, die neben der Untersuchung des gewählten Lösungsansatzes, der Validität, Semantik und Barrierefreiheit auch die Einhaltung dieser Richtlinien als Ziel haben. Dies betrifft sowohl Markup (HTML) als auch Stylesheets.

Beispiel

Ein kleines Beispiel-Stylesheet – nicht vollständig und in Bezug auf Schriftgrößen auch »suboptimal« – soll an dieser Stelle einen Vorgeschmack auf die GMX-Stylesheets und die für sie geltenden Richtlinien geben. Es umfasst zwei speziell für diese Dokumentation nachbearbeitete Snippets aus dem generischen sowie dem Formularmodul:

@charset 'utf-8';

/* ----- Core Module ----- */

* {
  margin: 0;
  padding: 0;
}

html {
  background: #C1D2EC;
  color: #000;
  direction: ltr;
  font: 400 11px/14px verdana, arial, helvetica, sans-serif;
}

/* ----- Width Settings Module ----- */

.s {
  width: 40px;
}

.m {
  width: 125px;
}

.l {
  width: 172px;
}

.xl {
  width: 220px;
}

/* ----- Form and Control Module ----- */

.form {
  background: #E8EEF5;
  padding: 7px;
}

.form.inverse td {
  font-weight: 700;
}

.form.inverse td span {
  font-weight: 400;
}

.form-control {
  margin: 10px 0 20px;
  text-align: right;
}

/* ----- Note Module ----- */

.note-1 {
  color: #244E7E;
  height: 14px;
  text-align: right;
}

.note-2 {
  color: #000;
  margin: 0 0 10px;
}

Alle Stylesheets sind auf technische Validität zu prüfen. Dieser Schritt ist generell direkt in die Arbeit an allen Vorlagen, ob XML, XHTML oder CSS, zu integrieren und damit nicht erst Bestandteil einer etwaigen Code-Review.

Richtlinien

Einrückung

Deklarationen innerhalb von externen Stylesheets sowie style-Elementen sind aus Gründen der Übersichtlichkeit um eine Tabulator-Länge einzurücken. Selektoren und schließende Klammern werden nicht eingerückt.

Falsch:
.success {
border: 1px solid;
}
Richtig:
.success {
  border: 1px solid;
}

In einer Zeile steht immer nur eine Deklaration.

Klammersetzung

Die öffnende Klammer steht immer in der Zeile des Selektors oder der @-Regel. Zwischen Selektor/Regel und der öffnenden Klammer ist ein Leerzeichen einzufügen. Die schließende Klammer steht immer in einer eigenen Zeile.

Falsch:
div
 {
  border: 1px solid #F00;
  color: #000;}
Richtig:
div {
  border: 1px solid #F00;
  color: #000;
}
Leerzeichen zwischen Eigenschaft und Wert
Falsch:
font-style:italic;
Richtig:
font-style: italic;

Diese Regel dient speziell der Übersichtlichkeit des Codes.

Semikolon hinter jeder Deklaration

Hinter ausnahmslos jede Deklaration – auch die letzte innerhalb einer Regel – ist ein Semikolon zu stellen.

Falsch:
display: inline
Richtig:
display: inline;

Diese Regel dient weniger der Vereinheitlichung denn vielmehr der marginalen Sicherstellung, dass betroffene Deklarationen ohne weiteres gruppiert werden können.

Alphabetische Sortierung von Deklarationen
Falsch:
div {
  color: #000;
  font-variant: small-caps;
  border: 1px solid;
}
Richtig:
div {
  border: 1px solid;
  color: #000;
  font-variant: small-caps;
}
Verwendung von Kurzschrift-Eigenschaften

In der Regel sind Kurzschrift-Eigenschaften zu verwenden, um den Code möglichst schlank zu halten.

Falsch:
border-style: none;
Richtig:
border: 0;

Diese Anforderung ist jedoch nicht trivial, denn zeitgleich soll und muss aus Wartbarkeitsgründen von Vererbung profitiert werden. Werden zum Beispiel alle h1-Überschriften mit einem bestimmten Außenabstand bedacht (wie margin: 1em 0 1.5em;), so wird nicht empfohlen, bei einer speziellen Überschrift, bei der der Außenabstand zu einer einzigen Seite angepasst wird, die Kurzschreibweise zu verwenden. In diesem Fall sollte die jeweils angemessene Spezialeigenschaft eingesetzt werden (wie margin-bottom: 2em;).

Werte

Bezüglich CSS-Werten ist auf drei Fälle besonders zu achten, nämlich auf URIs, Farbwerte sowie Werte der font-weight-Eigenschaft.

Bei Gebrauch des url()-Werts sind keine Anführungszeichen zu verwenden, da dies zumindest bei der background-image-Eigenschaft dazu führt, dass unter dem Internet Explorer (Mac) die entsprechenden Bilder nicht angezeigt werden. Somit gilt:

Falsch:
h1 {
  background-image: url('https://example.com/foo.gif');
}
Richtig:
h1 {
  background-image: url(https://example.com/foo.gif);
}

Farben sind in hexadezimaler Form zu definieren, dabei ist die Kurznotation der Langnotation vorzuziehen. Es sind Großbuchstaben zu verwenden.

Falsch:
p {
  color: #00ff00;
}
Richtig:
p {
  color: #0F0;
}

Als Werte für font-weight sollen nur 400 (anstatt normal) und 700 (anstatt bold) eingesetzt werden. Ausnahmen sind zu definieren; die Schlüsselwörter lighter und bolder sollten in der Praxis kaum zum Einsatz kommen, alle anderen Gewichtswerte werden nicht unbedingt solide unterstützt.

Referenzierung

Externe Dateien sind immer über url() zu referenzieren.

Falsch:
@import "https://example.com/css";
Richtig:
@import url(https://example.com/css);

Selektorenreihenfolge

Regeln sind nach invertierter Spezifität zu sortieren, wobei kombinierte Selektoren an der Stelle einzuordnen sind, an der deren zuerst kommender Selektor, für sich betrachtet, eingeordnet werden würde. Bei gleicher Spezifität sollen erst Regeln mit Selektoren für Block-, dann für Inline-Elemente genannt werden. »Semantischere« Selektoren (h1) stehen vor »unsemantischeren« (div). (Dieser Absatz ist auf Vollständigkeit zu prüfen.)

Falsch:
h1, h2, h3 {
  font-weight: 400;
}

a img {
  border: 0;
}

html {
  background: #CCC;
}

#warning {
  color: #F00;
}

a {
  border-bottom: 1px solid;
  text-decoration: none;
}
Richtig:
html {
  background: #CCC;
}

h1, h2, h3 {
  font-weight: 400;
}

a {
  border-bottom: 1px solid;
  text-decoration: none;
}

a img {
  border: 0;
}

#warning {
  color: #F00;
}

Kommentare

Die Verwendung von Kommentaren ist prinzipiell freigestellt. Bei temporären oder Sonderlösungen sollten jedoch auf jeden Fall Kommentare verwendet werden, um das Nachvollziehen solcher Umsetzungen zu erleichtern. Des weiteren muss bei Verwendung von spezifischen Workarounds oder »Hacks« für bestimmte Browser ein kurzer Kommentar bezüglich des oder der betroffenen User-Agents hinzugefügt werden, um so gekennzeichnete Regeln oder Deklarationen leicht entfernen zu können, wenn der betroffene User-Agent nicht mehr unterstützt werden muss:

Falsch:
div {
  width: 500px;
  voice-family: "\"}\"";
  width: 400px;
  voice-family: "\"}\"";
}
Richtig:
div {
  width: 500px; /* IE 5.x */
  voice-family: "\"}\"";
  width: 400px;
  voice-family: "\"}\"";
}

(Das Beispiel verwendet eine modifizierte Variante von Tantek Çeliks Boxmodell-Hack.)

Dient eine ganze Regel nur einem bestimmten User-Agent, so ist die folgende Kennzeichung zu empfehlen:

Falsch:
#main {
  width: 750px;
}
Richtig:
#main { /* IE 5.x */
  width: 750px;
}

Ist eine ganze Browser-Familie betroffen, so ist die Angabe der Versionsnummer(n) obsolet – in diesem Fall darf zum Beispiel /* IE */ als Verweis gebraucht werden. Sind Browser einer bestimmten Render-Engine betroffen, genügt die Angabe der Engine, zum Beispiel /* Gecko */.

Nachtrag (21. Dezember 2006)

Zum Vergleich und als mögliche Alternative empfiehlt sich ein Blick auf die just veröffentlichten HTML- und CSS-Code-Richtlinien bei Aperto.

Nachtrag (1. Januar 2016)

… oder auf die von Google, oder darauf, was es so bei Code-Richtlinien zu beachten gibt.

Mit freundlicher Genehmigung der GMX GmbH München.

Hierüber tooten?

Über mich

Jens Oliver Meiert, am 30. September 2021.

Ich bin Jens, und ich bin ein Engineering Lead und Autor. Ich habe als technischer Leiter für Firmen wie Google gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Bücher für O’Reilly und Frontend Dogma. Ich experimentiere gerne, nicht nur in der Webentwicklung, sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.

Wenn du eine Frage oder Anregung zu dem hast, was ich schreibe, sende bitte jederzeit eine Nachricht. Danke!