Logo: Pisto – Magazin über Web und die Welt

Magazin über Web und die Welt

CSS – wir räumen auf! von Andreas Dölling

Titelbild: CSS – wir räumen auf!

Während es für den Aufbau von HTML-Seiten und -Templates und erst recht für Scripts, Klassen und Funktionsbibliotheken im Backend allgemein anerkannte Regeln und in den meisten Fällen auch detaillierte firmeninterne Richtlinien gibt, herrscht in CSS-Dateien oft das Chaos. Warum eigentlich?

Mit diesem Artikel möchte ich einmal ein wenig Werbung machen für mehr Ordnung in den Stylesheets. Und zwar nicht, weil ich mir gerne besonders schöne Stylesheets ausdrucke und an die Wand hänge, sondern weil ich als Freelancer regelmäßig in fremden CSS-Dateien arbeite und es immer wieder nervend und zeitraubend ist, mich durch das oft vorzufindende Wirrwarr hindurchzuquälen.

Das Kind braucht einen Namen!

Der kleinste gemeinsame Nenner und eigentlich eine Selbstverständlichkeit sind ein einheitliches Layout für die Stylesheets und eine konsistente Namensgebung für Klassen und IDs.

Die Layout-Möglichkeiten sind jetzt nicht so mannigfaltig. Man sollte sich also problemlos darauf einigen können, wie Klammern, Umbrüche und Einzüge zu setzen sind. Das von mir favorisierte Layout spreche ich im letzten Abschnitt an.

Hinsichtlich der Bezeichner gibt es ebenfalls einige wenige Vorgaben, auf die man sich einfach einigen muss:

  • Sprache (also Deutsch, Englisch, ...),
  • Schreibweise (also "meineKlasse", "meine_klasse" oder "meine-klasse") und
  • Semantik (nach welcher Logik erfolgt die Benennung?).

Der dritte Punkt ist derjenige, der am meisten Kopfzerbrechen bereitet und – durchaus aus genau diesem Grunde – sehr oft vernachlässigt wird. Das rächt sich zumindest bei größeren Projekten dann später regelmäßig. Meistens zu einem Zeitpunkt, zu dem es für grundlegende Änderungen zu spät ist, so dass gezwungenermaßen eine Nachlässigkeit jeweils vier, fünf Notlösungen nach sich zieht: schlechte Bezeichner, überflüssige Klassen und/oder überflüssiges Markup.

Ich hatte in den letzten Monaten mehrmals die Gelegenheit, in einer großen IT-Firma zu arbeiten, in der sehr hohe Qualitätsanforderungen gelten. Der Kollege, mit dem ich am Frontend arbeitete und der für die Qualitätssicherung zuständig war (jawohl: dort gibt es eine QS auch für HTML-Templates, CSS-Stylesheets und JS-Scripts – und zwar eine QS, die diese Bezeichnung auch verdient), verbrachte enorm viel Zeit damit, eine schlüssige Benennung der Klassen und IDs zu entwickeln. Ich hielt das anfangs für maßlos übertrieben und ärgerte mich ein wenig über die ständigen Änderungen, die er verlangte. Schnell erkannte ich dann aber, dass der Mann sehr richtig lag und uns durch seine Überlegungen viel Ärger ersparte.

Es gab beispielsweise eine verschachtelte Liste, die per Javascript auf- und zuklappbar war. Ich knüpfte zunächst alle Styles und auch die JS-Logik an eine Klasse:

<div class="country-selection">
    <ul>
        <li>...</li>
    </ul>
</div>

Alles hing an der Klasse "country-selection". Ich fand das zunächst gut, weil ich so mit nur einer einzigen Klasse auskam.

Mein Kollege war allerdings nicht einverstanden und schlug vor, alle CSS-Angaben, die mit dem Aus- und Einklappen zu tun haben, an eine separate Klasse zu binden und diese der ul-Liste zuzuweisen. Ich setzte seinen Änderungswunsch um, und heraus kam dies:

<div class="country-selection">
    <ul class="collapsible">
        <li>...</li>
    </ul>
</div>

Sieht erst einmal nach einer überflüssigen Klasse aus. Aber: Wir haben dadurch viel gewonnen, nämlich zum einen eine Klasse "country-selection", die nicht überfrachtet ist mit Styles, die nicht spezifisch für die Länderauswahl-Box sind. Und zum anderen eine universell einsetzbare Klasse "collapsible", die unabhängig vom Kontext funktioniert und deren Bezeichner ganz klar sagt, was sie tut.

Ein anderes Beispiel sind die Adjektive "active" und "inactive", die einige andere Kollegen und ich etwas zu beliebig als Klassennamen einsetzten:

  • in einer Box mit einer Reiternavigation für die Zustände der Reiter und der dazugehörenden Inhalte,
  • für Formularelemente, die editierbar waren oder eben nicht,
  • für Icons, die man per Klick ein- und ausschalten konnte, und
  • für ausgeklappte Navigationsbereiche.

Unser QS-Mann fand das nicht ganz so praktisch wie wir und forderte passende Benennungen. Er bemängelte, dass wir ein und denselben Bezeichner mit völlig unterschiedlichen Bedeutungen verwendeten. Und dass unsere Bezeichner zum Teil auch sprachlich unpassend seien. So sei ein Reiter in einer Tab-Navigation, der anklickbar sei, ja durchaus nicht "inaktiv". Er sei nur gerade eben nicht ausgewählt. Genauso wenig sei ein ausgeklappter Navigationsbereich "aktiv", ein nicht sichtbarer aber "inaktiv". Nein, sie seien einfach ausgeklappt oder eingeklappt, nicht mehr und nicht weniger.

Tja, was sollten wir sagen? Der Mann hatte mal wieder recht. Und nicht nur die Entwickler, die nach uns irgendwann einmal wieder mit den Stylesheets und Templates arbeiten müssen, werden es ihm danken, sondern auch die Backend-Kollegen, die unsere Templates verwursten müssen, ohne die Muße zu haben, sich nun in in alle Details unserer HTML-Konstrukte zu vertiefen, sondern glücklich sind über Bezeichner, die tatsächlich das bedeuten, wonach sie klingen.

Sie sind uns eine Erklärung schuldig!

Der Erklärungsbedarf innerhalb eines CSS-Stylesheets hält sich sicherlich in Grenzen, wenn man zum Vergleich eine Java-Klasse oder etwas dergleichen heranzieht. Dennoch sollte man die Möglichkeit, erläuternde Kommentare zu setzen, durchaus auch in der CSS-Welt nutzen. Das kann den Kollegen oder einem selbst – wenn man die Datei ein Jahr später wieder öffnet – viel Kopfzerbrechen und das eine oder andere Magengeschwür ersparen.

Allzu geschwätzig muss es dabei ja gar nicht zugehen – die CSS-Datei ist zum Beispiel nicht so ganz der passende Ort, um zu beschreiben, was die Eigenschaft position so alles tut…

Es geht vielmehr darum, CSS-Angaben zu erklären, die unnötig oder vollkommen hanebüchen erscheinen (wie zum Beispiel die Lösung für Listen neben float-Elementen). Oder im IE-Stylesheet den jeweiligen Bug zu benennen, der durch die einzelnen Angaben umgangen wird.

Es reichen ja meistens ein kurzes Stichwort und gegebenenfalls eine URL, unter der mehr Information zu finden ist. Und schon wird die Angst, jemals wieder an dieses eine vollkommen vertrackte Projekt Hand anlegen zu müssen, ein ganzes Stück geringer. Als Politiker würde ich jetzt noch das Wort »Nachhaltigkeit« unterbringen, aber ich bin ja zum Glück keiner.

Bei den Webkrauts hat übrigens Dirk Jesse einen Artikel zur Kommentierung von CSS-Stylesheets geschrieben. Er verweist darin auf CSSDOC, einen Vorschlag zur standardisierten Kommentierung von CSS-Stylesheets analog zu ähnlichen Quasi-Standards im Programmierbereich.

Immer schön der Reihe nach!

Vor Jahren machte ein ehemaliger Arbeitskollege in einer Projektbesprechung einen Vorschlag. Er beschwerte sich über die geradezu monströsen über Monate und Jahre hinweg gewucherten und von Redundanzen wimmelnden Stylesheets, mit denen wir uns bei diversen Web-Projekten herumschlugen, und regte an, den Wildwuchs zumindest ein wenig zurückzuschneiden durch Erlass einer für alle verbindlichen Regel, fortan besonders wichtige CSS-Angaben – etwa über Dimensionen und Abstände von Elementen – stets an den Anfang einer Regel zu setzen. Der Vorschlag des Kollegen ging damals allerdings unter. Der Mann kämpft vermutlich noch heute heroisch gegen die firmeninterne CSS-Hydra. Ich selbst behielt die Idee im Hinterkopf, griff bei einem eigenen Projekt darauf zurück und fand, dass sie ebenso gut wie einfach ist.

Aufbauend auf die Gedanken des Kollegen teilte ich die CSS-Eigenschaften in Gruppen ein. Diesen wies ich anschließend einen Rang zu, der so ungefähr die Wichtigkeit der jeweiligen Gruppe von Eigenschaften widerspiegelte: je größer die Auswirkungen von Eigenschaften auf das Layout, desto wichtiger. Heraus kam diese Rangordnung:

  1. Verhalten (position, float, display),
  2. Position und Dimension (top/bottom, left/right, width, height),
  3. Abstände und Rahmen (margin, padding, border),
  4. Schriftgröße und Zeilenhöhe (font-size, line-height),
  5. Hintergrund (background) und
  6. übrige Eigenschaften.

Und genau in dieser Reihenfolge stehen nun die jeweiligen Eigenschaften, sofern gesetzt, in den einzelnen CSS-Regeln.
Das klingt jetzt vielleicht nicht besonders revolutionär, aber dem einfachen CSS-Malocher draußen im Lande – also mir zum Beispiel – erleichtert auch diese einfache Regelung das Leben wieder ein kleines bisschen, insbesondere wenn er mit anderen zusammen an einem Projekt arbeitet.

Nicht quer denken, quer schreiben!

In allen Teams, mit denen ich bislang im Frontend zusammengearbeitet habe, wird entweder explizit oder weil es sich halt so ergeben hat, eine Schreibweise für die CSS-Stylesheets verwendet, die an die Formatierung von Blöcken in Programmiersprachen erinnert:

selektor
{
    eigenschaft1: wert1;
    eigenschaft2: wert2;
}

Das sieht auf den ersten Blick natürlich wunderbar übersichtlich und ordentlich aus und bietet zum Beispiel den Vorteil, dass man einzelne CSS-Angaben gut kommentieren kann oder gleiche Regeln für verschiedene Selektoren gut zusammenfassen kann:

selektor1,
selektor2
{
    eigenschaft1: wert1;
    eigenschaft2: wert2;    /* Kommentar zu dieser Angabe */
}

Dennoch mag ich diese Art, CSS-Dateien aufzubauen, nicht. Insbesondere stört mich, dass mit diesem Layout schon kleine und wenig komplexe Stylesheets schnell zu Endlosdokumenten mit mehreren Hundert Zeilen werden. Die Übersichtlichkeit ist aus meiner Sicht nur eine scheinbare, die sich in der Praxis nicht bewährt.

Ich mag es:

  • wenn ich mir möglichst schnell einen Überblick darüber verschaffen kann, welche HTML-Konstrukte es in einem Projekt gibt,
  • wenn ich schnell erkennen kann, welche Selektoren zu den einzelnen Konstrukten gehören,
  • und wenn ich schnell zwischen den einzelnen Regelgruppen hin und herspringen kann ohne mir den Finger wundzuscrollen oder ständig die Suche nutzen zu müssen.

Und dies erreiche ich am allerbesten mit einer Schreibweise, die im Programmierbereich aus guten Gründen verpönt ist: indem ich nämlich – jetzt müsst ihr ganz tapfer sein! - jede Regel mitsamt den dazugehörenden Angaben jeweils in einer Zeile zusammenziehe:

selektor1 { eigenschaft1:wert1; eigenschaft2:wert2; }
selektor2 { eigenschaft1:wert3; eigenschaft4:wert4; }

Das wird auf die meisten von euch jetzt abschreckend, wenn nicht – um es mal mit Lovecraft zu formulieren – geradezu »blasphemisch« wirken. Und bisher konnte ich mich damit auch in noch keinem einzigen Projekt durchsetzen, das ich im Team bestritten habe.

Dennoch behaupte ich, dass meine Schreibweise praktischer und übersichtlicher ist – vor allem dann, wenn man gleichzeitig Regeln für die Reihenfolge der einzelnen Angaben vereinbart, wie ich sie im vorigen Abschnitt vorgeschlagen habe.

Erklärungsbedürftige CSS-Angaben kann man natürlich in dieser Schreibweise nicht so schön kommentieren wie in der Blockschreibweise – aber in solchen Fällen kann man sich damit behelfen, die zu kommentierende Angabe in eine eigene Zeile zu schreiben oder den Kommentar über die Regel zu setzen.

Schauen wir uns doch mal einen Ausschnitt aus einem echten Stylesheet in beiden Schreibweisen an:

CSS im Vergleich

Wie hättet ihr euer CSS gerne: in Blöcken oder in Streifen?

Welche der beiden Varianten bietet mehr relevante Information auf den ersten Blick? Ich sage: meine Variante – und davon wird mich auch die Heilige CSS-Inquisition nicht abbringen (außer mit Androhung von Gewalt vielleicht – oder mit viel Geld – oder einer klassizistischen Strandvilla an der Ostsee …).

Probiert es einfach einmal aus!

Der Autor

 Andreas DöllingAndreas Dölling arbeitet seit 1999 als Web- Entwickler, kann es aber nicht lassen, seine Nase immer wieder in Bereiche zu stecken, die ihn eigentlich gar nichts angehen, und seine Meinung dazu kundzutun.

Titelbild: »Dirty dishes« von AlesVeluscek via istockphoto.com

22.09.200814 Kommentare

Stichwörter:

Kommentare

Bis auf das quer schreiben bin ich mit allem einverstanden und wird bei uns auch so umgesetzt.

Nur leidet beim quer schreiben vll anfangs die Übersichtlichkeit, aber die Editierbarkeit geht mir dabei verloren.
Wieso also das Einklappen nicht dem Editor überlassen? Ich habe das Glück das wir mit Textmate arbeiten können, da genügt ein Druck auf CMD+0 (oder jede andere Zahl auf dem Nummernblock) und er klappt mir alle Funktionen/Klassen ein (siehe: http://www1.minpic.de/bild_anzeigen.php?id=28145&key=23938284&ende)

Ich weiß nicht wie es bei anderen Editoren aussieht, hoffe aber doch das sie so eine grundlegende Funktionalität auch bieten?

Es gibt eine heilige CSS-Inquisition? Ach so, das bin ja dann wohl ich! So lest diese unsere Replik und schwört ab Eurem Irrglauben!

Die Unfähigkeit eines ordentliches Naming und inhaltlich sinnvoller Kommentierung scheint mit ein weit verbreitetes Phänomän zu sein. Zwar hacke ich als Programmierer nur selten HTML/CSS, wirre Strukturen im Sourcecode sind mir aber leider ebenfalls ein Begriff.

Ich kann mich mit dem Querschreiben irgendwie überhaupt nicht anfreunden. Klar, wenn man einen normalen Text-Editor für CSS benutzt, mag man auf anhieb mehr information erfassen können. Aber ist das nötig?

Ausserdem benutze ich und so ziemlich viele/alle aus meinem WebDev Umfeld einen CSS-Editor mit einer schönen Selektoren-Übersicht (zB CSS-Edit). Und ist "mehr auf einen Blick" wirklich übersichtlicher? Denke nicht.

Ich find es in einer Zeile zudem schwieriger eine bestimmt Eigenschaft ausfindig zu machen. Ab 4-5 Eigenschaften muss bei längeren Selektoren auch noch horizontal gescrollt werden. Das mag ich gar nicht.

Aber was den Rest angeht stimme ich Dir zu. :-)

Danke für Eure Wortmeldungen! Dass ich jetzt die »CSS in Streifen«-Revolution anstoße, hatte ich übrigens nicht unbedingt erwartet.
;)
Wichtig - oder sagen wir besser: vorteilhaft - ist, dass man sich in einem Team auf eine Vorgehensweise hinsichtlich der im Artikel genannten Punkte einigt und dann auch konsequent dabei bleibt - und was das angeht, habe ich eben recht unterschiedliche Erfahrungen gemacht.
Zu Schaden an Leib und Seele ist dabei allerdings nie jemand gekommen. Es ist letztlich eben doch nur - CSS.

Witzig, die Gruppeneinteilung habe ich genauso gemacht. So fällt es mir auch am leichtesten und es bleiben Sinnabschnitte.

Auch sonst gefällt mir der Artikel sehr gut, schön, dass ihr gleich von Anfang an durch eine gute Qualität besticht. Lieber mal länger warten und dafür einen ausgearbeiteten Artikel lesen können.

Danke!

100% Zustimmung dazu, dass eine (wie auch immer im Detail gelöste) Konvention über Anordnung und Schreibweise zu höhere Produktivität führt. Nicht umsonst gibt es auch für die meisten Programmierprojekte Styleguides. Drupla zB formatiert sogar eingebundene Drittbibliotheken gemäß dem eigenen Stil um.

Womit ich allerdings wenig anfangen kann, ist die Auflösung von einer auf mehr als einen Selektor zutreffende Regel auf einzelne identische Regeln. Ich setze das gerne ein, wenn ich einen spezifischen Stil synchron an mehr als einer Stelle benötige - auch bei späteren Revisionen.

Ganz starker Artikel - ich bin ganz deiner Meinung! Ich schreibe schon seit Jahren meine CSS-Eigenschaften in eine Zeile und finde es extrem übersichtlich. Eine durchgängige konsequente Reihenfolge hilft dabei sicherlich. Vor einiger Zeit habe ich die Schreibweise bei uns im Team eingeführt und kann darüber nur Positives berichten. Nach meiner Erfahrung verhilft das Querschreiben gerade bei Anfängern sich an die Kurzschreibweise zu halten - damit eben die Zeilen nicht so lang werden :) Und mal ehrlich - nach max 150 Zeichen ist bei mir meistens Schluss mit den Eigenschaften und die passen auf meinen Widescreen locker drauf. Das man Aussehen und Verhalten in unterschiedliche Klassen kapselt finde ich eine sehr gute Idee. Meiner Meinung nach spricht aber nichts dagegen die Klassen ein und dem selben Tag zuzuweisen und somit Markup einzusparen:

<ul class="country-selection collapsible">
    <li>...</li>
</ul>

Also es geht nichts einfacher als alpahbetisch die Eigenschaften sortieren und das CSS in Blöcken zu schreiben. Am Ende erstellt man sich eine Arbeits-Datei und eine Live-Datei die man durch einen Kompressor gejagt hat.

Ich kann Dir in allen Punkten zustimmen. Auch ich schreibe meine CSS-Regeln in einer Zeile. Ich finde das genau wie Du sehr viel übersichtlicher, die Datei wird kürzer. Ich tue dies vor allem an der Arbeit, da habe ich auch ein sehr breites Display (1920er). Bei meinem 1280er zuhause wird das schon enger. Auch die Reihenfolge mache ich ähnlich, aber eher implizit und aus dem Bauch heraus. Deine Erklärung und Staffelung hat mir sehr gut gefallen. Danke.

ja, endlich!
Ich bin auch, wenn zwar keine Verfechterin, aber eine Anwenderin der "Quer-Schreibweise"

kommt vielleicht daher, daß ich noch aus der Generation stamme, die zuerst schrieb und dann programmierte...

ich mag diese meterlangen Definitionen nicht, und habe mir angewöhnt, wenn ich solche Dateien aufräumen muss, die bearbeiteten Zeilen zusammenzufassen und quer zu schreiben, so schnurrt die putzende Datei immer mehr zusammen und ich weiß was ich schon gemacht habe

Nützlich sind auch Kommentarzeilen mit einer merkbaren Zeichenkombination zu Abschnittsanfängen,z.B. ###, kann man mit [CTRL-F] dann gut anspringen

bei der querschreibweise kann man aber nicht
turbo-like shit+cursor eine ganze eigenschaft markieren.

Sehr schöner Artikel. Ich habe zuvor auch noch nie die "Querschreibweise" in Projekten angewendet. Aber ich werde es in Zukunft sicherlich tun. Schönen Dank für den herrlichen Vergleich. Desweiteren werde ich mir die Reihenfolge der CSS-Eigenschaften zu Herzen nehmen.

Sehr interessanter Beitrag. Vielen Dank!
Stimme dir bis auf eine Kleinigkeit auch voll zu. Ich finde das mit dem quer schreiben etwas gewöhnungsbedürftig.

Werbe-Kommentare werden wir übrigens löschen. Im Zweifel nehmen wir zumindest den Link zur beworbenen Homepage raus.

Es gibt zu diesem Artikel einen Kommentar-Feed