CSS: Einfache Regeln zur Organisation und Effizienzsteigerung

Artikel vom 15. Mai 2008 (↻ 14. Februar 2013). ISSN 1614-3124, #37. Schwerpunkt:  (RSS-Feed).

Dieser und viele andere Beiträge sind auch als hübsches, wohlerzogenes E-Book erhältlich: On Web Development. Wenn Sie sich speziell mit der Optimierung von CSS beschäftigen, ich habe einige Grundlagen in einem kleinen Buch zusammengetragen: CSS Optimization Basics.

»Organisation ist nicht alles, aber ohne Organisation ist alles nichts«, habe ich einen Lehrer in Erinnerung, und damit hat er recht. Nahezu alles profitiert von Organisation, und entsprechend auch die Arbeit mit CSS – insbesondere, wenn man mit mehreren Menschen zusammenarbeitet. Im Laufe der Jahre habe ich mich häufig um organisatorische Standards bemüht, hauptsächlich für HTML und CSS (siehe Code-Richtlinien für GMX sowie für Aperto), und es sollten hinreichend Nachweise für die Vorteile von solchen Standards existieren.

Davon unabhängig brachte die Zeit zusätzliche Verfeinerungen meiner persönlichen CSS-Code-Richtlinien, von denen hier drei einfache Regeln vorgestellt werden, die der konsistenten Organisation sowie verbesserter Effizienz dienen und Inspiration bedeuten sollen.

Nach Selektoren sortieren und gruppieren

Webentwickler, die einen »modularen Ansatz« wählen, befolgen dies tendentiell, aber es ist definitiv lohnenswert, die Selektorenreihenfolge zu standardisieren, sowohl für einen selbst als auch das beteiligte Team. Die Reihenfolge, die ich selbst gegenwärtig für in eigenen Projekten verwendete Selektoren definiere, lautet wie folgt (auch wenn sie nicht alle Selektorarten beinhaltet):

*, html, body, h1, h2, h3, h4, h5, h6, p, address, blockquote, pre, ul, ol, li, dl, dt, dd, table, caption, tr, th, td, form, fieldset, legend, label, input, textarea, div, img, a, strong, em, abbr, q, cite, code, kbd, var, span, #id, .klasse

Diese Sortierweise funktioniert sowohl »vertikal« als auch »horizontal«:

ul, li, .hinweis {}
ul {}
li {}
.hinweis {}

Die Regel wird etwas komplexer, wenn man »kontextuelle« Selektoren einbezieht: Hier mag dieselbe Reihenfolge (also beispielsweise p em, p abbr {}) angewandt werden, wobei einfachere Selektoren zuerst folgen (wie im etwaigen Fall p, p em, p abbr {}). Eine weitere nennenswerte Unterregel ist zudem die Ordnung, die für Selektoren wie p und p.warnung gelten und in p, p.warnung resultieren sollte (oder p, .warnung, gleichwohl in obiges Schema passend), erneut vertikal und horizontal anwendbar.

Zugegebenermaßen ist diese Beschreibung mathematisch nicht ganz hinreichend und exakt das beschreibend, womit bereits gute Erfahrungen gesammelt werden konnten. Man kann alternativ auf ihr aufbauen, indem man einen »modulzentrierten« Weg sucht, bei dem man die vorgestellte Reihenfolge nur innerhalb von CSS-Abschnitten anwendet (wie etwa Navigationsregeln), oder sie entsprechend zusätzlicher Anforderungen weiter ausformuliert.

Nachtrag (14. Februar 2013)

Ich habe einen umfassenderen Entwurf zur Sortierung von Selektoren veröffentlicht.

Jede Deklaration nur einmal verwenden

Genau: Jede Deklaration nur einmal verwenden. Der Grund dafür ist, dass Deklarationen im Durchschnitt länger als Selektoren sind und die Größe von Stylesheets damit wachsen lassen, womit diese logischerweise auch mehr Zeit zum Laden benötigen. Ein weiterer Grund ist das schöne Kopfschütteln, das man äußern kann, wenn CSS-Variablen (nicht Selektorvariablen) zur Sprache kommen – in vielen Fällen wird man diese vermutlich nicht brauchen, und zwar überhaupt nicht.

Ein realistisches, wenn auch gekĂĽrztes Beispiel fĂĽr diese Regel ist (durchaus unter der Annahme, dass dieses Stylesheet vielleicht insgesamt 50 Regeln beinhaltet):

h1, h2, h3 { font-weight: normal; }
a strong { font-weight: normal !important; } /* exemplarisch, als gegeben anzusehen */
strong { font-style: italic; font-weight: normal; }
#nav { font-style: italic; }
.hinweis { font-style: italic; }

Anwendung der »jede Deklaration nur einmal«-Regel macht daraus bereits

h1, h2, h3, strong { font-weight: normal; }
a strong { font-weight: normal !important; }
strong, #nav, .hinweis { font-style: italic; }

Dies spart einige Zeichen (und Ladezeit), ohne dabei im Weg zu stehen: Letztendlich geht es bei der Formatierung von HTML-Dokumenten eben um die Darstellung, so dass die Konzentration auf Deklarationen um so besser funktioniert.

Es gibt zu dieser Methode dennoch vier wichtige Dinge anzumerken:

Deklarationen alphabetisch sortieren

Es gibt wohl unzählige Vorgehensweisen, Deklarationen innerhalb von Deklarationsblöcken zu sortieren, aber die einfachste und »kognitiv anspruchsloseste« ist die alphabetische Sortierung. Anstatt also erst an Maßangaben, dann Farben, dann Größen und so weiter zu denken, bietet sich an, alphabetisch vorzugehen:

#content {
  border: 1px dashed;
  color: #000;
  margin: auto;
  padding: 1em 0;
  width: 700px;
}

Zwar haben andere Sortierweisen (oder auch überhaupt keine) ebenfalls ihre Freunde, aber es darf aus eigener Erfahrung behauptet werden, dass diese Regel einfach und zielführend ist, sobald man sich daran gewöhnt hat – was recht schnell geschieht.

Beispiel

Um all diese Tipps einmal in Aktion zu zeigen (mitsamt etwaigen Inkonsistenzen von meiner Seite), folgt ein Ausschnitt des 2006er Stylesheets von WHWS:

@media screen, projection {
  * { margin: 0; padding: 0; }
  html { background: #000; color: #ccc; font: 87.5%/1.5 optima, arial, sans-serif; text-align: center; }
  body { margin: 1em 0; }
  h1, h2 { font-size: 1em; font-weight: normal; }
  h1 { background: url(/media/logo.jpg) no-repeat; height: 366px; text-indent: -999em; width: 620px; }
  h2, p { margin: 0 .5em; }
  p + p { text-indent: 1em; }
  p#ref { background: url(/media/end.jpg) no-repeat bottom center; margin: 1.5em 0 0; padding-bottom: 179px; }
  ul { margin: .5em 0 .5em 1.5em; }
  ul#lang { list-style: none; margin: .5em 0 1em 1.5em; }
  ul#lang li { display: inline; }
  div#show { margin: auto; text-align: left; width: 619px; }
  div#whws { background: url(/media/tape.png) repeat-y top center; margin: 42px 0; }
  div#whws + div { position: relative; }
  a, strong { color: #fff; }
  strong { font-size: 1.3em; line-height: 1; }
  kbd { font-family: optima, arial, sans-serif; }
}

❧ Schlussendlich: Verwenden Sie, was für Sie geeignet ist, und wenn dies heißen mag, dass Sie sich höchstens inspiriert fühlen, diese Regeln in einem kleinen Projekt oder auf die zuvor erwähnte modulspezifische Art einzusetzen. Was in äußerst komplexen Projekten übrigens einen guten Ansatz darstellt.

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!