Die zwei englischsprachigen Artikel Single-Line vs Multi-Line CSS und Single Line CSS haben mich dazu gebracht ein paar Worte dazu zu schreiben wie ich meinen CSS-Code organisiere und warum ich es so mache. In den folgenden Beispielen, gehe ich von der Arbeit eines einzelnen Webworkers aus, da man sich in Gruppen auf ein gemeinsames Vorgehen einigen sollte.
Einzeilig, Mehrzeilig oder doch eine Mischform
Früher hatte ich die CSS-Regeln in mehrere Zeilen aufgeteilt:
#bla {
background: #ddd;
border: 1px solid #ccc;
margin: 12px;
}Ich übertreibe nicht wenn ich diese Schreibweise als klassisch bezeichne. Sie hat den Vorteil, dass sie übersichtlich ist und auch bei kleinen Monitorauflösungen eine gute Figur macht.
Diese Schreibweise hat den Nachteil, dass sie zunehmend eine sehr lange Datei produziert was ich persönlich dann unübersichtlich finde. Sicherlich, auch mein HTML-Editor WeBuilder * hat eine gute Suchfunktion, die Möglichkeit jedem Dokument “Lesezeichen” zu verpassen und einen Code-Explorer, der alle Selektoren auflistet, aber es bleibt für mich dennoch unübersichtlich.
Seit dem ich einen 24″-Monitor besitze, tendiere ich dazu die Regeln möglichst in eine Zeile zu schreiben:
#bla { background: #ddd; border: 1px solid #ccc; margin: 12px; }Diese Vorgehensweise hat den Vorteil, dass sie kürzere Dateien produziert, aber bei kleineren Monitoren, macht sie leider keine gute Figur. Wenn die CSS-Regel droht zu lang zu werden und dadurch auf mehrere Zeilen umzubrechen, dann teile ich Sie, in für mich logische, Teile auf:
#blubb { position: absolute; left: 0; top: 15px;
border: 1px solid #ccc; margin: 15px; padding: 10px;
background: #ddd url(bild.png) repeat-y; color: #333; }In dem oberen Beispiel habe ich drei Zeilen gemacht. Die erste kümmert sich um die Positionierung, die zweite Zeile widmet sich dem Box-Modell und die dritte ist zuständig für das “Make-Up”.
Man kann das gleiche Beispiel auch etwas mehr auflockern:
#blubb {
position: absolute; left: 0; top: 15px;
border: 1px solid #ccc; margin: 15px; padding: 10px;
background: #ddd url(bild.png) repeat-y; color: #333; }Ist Jacke wie Hose und daher Geschmackssache.
Alphabetisch oder nicht
Es wird an einige Stellen empfohlen, dass man die Deklarationen alphabetisch notiert, zum Beispiel:
#bla { background: #ddd; border: 1px solid #ccc; margin: 12px; }Ist an sich sinnvoll, weil man so sehr schnell die einzelnen Eigenschaften finden kann. Allerdings weiche ich manchmal von dieser Regel ab. Ein Beispiel habe ich schon vorhin aufgezeigt:
#blubb { position: absolute; left: 0; top: 15px;
border: 1px solid #ccc; margin: 15px; padding: 10px;
background: #ddd url(bild.png) repeat-y; color: #333; }Es ist für mich persönlich sinnvoller wenn ich die Deklarationen in einzelne (für mich) logische Gruppen aufteile, als wenn ich mich sklavisch an die alphabetische Reihenfolge halte. Innerhalb der einzelnen Gruppen kann man dann schon alpahbetisch vorgehen, aber auch da gibt es für mich Ausnahmen:
#blubb { position: absolute; left: 0; top: 15px;}Alphabetisch hin oder her, aber für mich ist es logischer das ich zuerst bestimme, wie ein Element positioniert ist und ihm dann die Koordinaten zu geben.
Einrücken oder nicht?
In einem Blogartikel fand ich den Tipp, die “untergeordneten” CSS-Regeln einzurücken:
body { ... }
#inhalt { ... }
p { ... }OK, sichtbarer ist das ganze schon, aber die Wartbarkeit des Codes hat sich in meinen Augen verschlechtert. Daher habe ich nach einer kurzen Testphase aufgehört den Code so einzurücken.
Abschnitte durch Kommentare trennen
Um die einzelnen Gruppen von Regeln zu trennen, kurze Erklärungen zu den Abschnitten einzufügen und CSS-Hacks zu dokumentieren sollte man mit Kommentaren nicht geizen, zum Beispiel:
/* #mitte: gruppiert den #inhalt und #sidebar */
#mitte { ... }Es gibt hier eine wahre Wissenschaft wie man die CSS-Kommentare gestalten soll. Man das ganze richtig ernst nehmen und sich nach den Regeln von CSSDOC halten. Hier gibt es spezielle Regeln, wie man zum Beispiel den Kommentar eines Abschnitts oder eines Unterabschnitts aufbaut:
/**
* @section layout
* @todo Die Hacks testen
*/Ich habe mir eine Zeit lang vorgenommen mich an die CSSDOC-Konventionen zu halten. Ich fand es dann aber nach einer Zeit recht mühsam, dass ich auch noch lernen muss, wie ich meine eigenen CSS-Kommentare gestalten und aufbauen soll. Hier fehlt mir noch der wirkliche praktische Nutzen.
Fazit oder olle Kamellen
Um den CSS-Code zu organisieren und damit für sich selber übersichtlicher und wartbarer zu machen, gibt es noch viele weitere Möglichkeiten: alle eingesetzten Farbcodes am Anfang aufzulisten, die einzelnen Abschnitte zu nummerieren und darauf basierend am Anfang der CSS-Datei ein Inhaltsverzeichnis zu erstellen etc. pp.
Aber auf die Gefahr hin, dass ich euch olle Kamellen erzähle, kann ich nur als Tipp weitergeben, dass jeder für sich alleine den Königsweg finden muss und das die ganzen Artikel ala “Ultimative Organisation des CSS-Codes” dir dann höchstens als Inspiration dienen sollte.
Die sklavische und unreflektierte 1:1 Übernahme solcher Tipps hat einen ähnlichen Mehrwert, wie wenn man sich genau so sklavisch die ganzen Selbstmanagement- und Selbstorganisations-Tipps zu eigen macht.
Menschen sind unterschiedlich, haben unterschiedliche Vorgehensweisen und es existieren eine Reihe von verschiedenen Entwicklungsumgebungen. Auch die unterschiedlichen Hardware-Einstellungen tragen zur unterschiedlichen Arbeitsweisen bei. Man arbeitet an einem 24″ Monitor anders als an einem 19″ Monitor und wenn man an zwei Monitoren arbeitet, dann eignet man sich in der Regel auch andere Vorgehensweisen an.
So, jetzt habe ich genug philosophiert. 🙂 Wie organisierst du deinen CSS-Code?
* = Partnerlink
Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienstleistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.
Ich finde die Einzeilenversion – so wie du erwähnt hast – nur dann praktisch, wenn es nicht zu lang wird.
Ich selbst bevorzuge (leider) die klassische Version (ich komme von C++) wenn ich aber in bereits vorhandenen CSS Dateien arbeite, passe ich mich dem Stil an.
Vielleicht kann ich deinen Artikel als Start in eine schöne, neue CSS-Einzeilenwelt verwenden 😉
LG,
Andreas Ostheimer
Nach der „rättischen Chaosmanier“ 😉
Danke für diesen Artikel noch vor Ostern; da kann ich feierliche Besserung am Karfreitag geloben und sams- sowie sonntäglich ein paar ordnende Eier legen.
Den Montag habe ich dann als Ass im Ärmel.
Muß echt was dran tun! 🙄
Lieber Gruß
Rata
Ich schreibe “klassisch” mehrzeilig, in den Blöcken kommen zuerst die Positionierungs-Angaben und dann der Rest, ich hab da irgendwie eine interne Logik…
Die Blöcke sind unterteilt in “Sinneinheiten”, erst body und allgemeines, dann der Seitenaufbau (page, header, sidebar, footer, …) dann die Inhalte der jeweiligen Blöcke (#content p, …).
Wenn ich merke, dass ein Bereich, (zB eine Navigation) eine große Menge eigenen Code braucht, bekommt sie einen eigenen (Sinn-)Abschnitt.
Diese Sinneinheiten trenne ich mit einem langen Kommentar, der weit nach rechts aus dem anderen Code herausreicht voneinander ab – so kann ich schnell durch eine Datei scrollen und muss nur rechts schauen, bis ich zB die Sidebar gefunden habe.
Das System passt sich natürlich immer an die Gegebenheiten an, funktioniert grundsätzlich seit ein paar Jahren recht gut.
Kurz gesagt, ich organisiere “klassisch” (wie du es im ersten Beispiel nennst) und ordne innerhalb einer Definition nach Möglichkeit so: Abstände und Rahmen, Größenangaben, Font-Bezogenes, Farbangaben, Weiteres).
Ansonsten gruppiere ich Definitionen thematisch und durch je eine Kommentarzeile kenntlich gemacht, angefangen mit den großen Element-Blöcken des Dokuments, in denen sich die übergeordneten DIV-Bereiche befinden: z.B. Seitenkopf, Inhaltsbereich, Sidebar, Seitenfuß. Dann folgen die grundlegenden Definitionen zu Hyperlinks, gefolgt von grundlegenden Definitionen zur Schriftdarstellung. Dann Listen aller Art, eventuell Tabellen, schließlich Bilder, bis hin zu immer feineren Einzeldefinitionen, sofern nötig.
Im Laufe der Lebenszeit einer CSS-Datei kommt da zwar immer etwas Durcheinander rein, aber den groben Überblick behalte ich auf diese Weise immer so weit, dass ich diese Grundordnung gelegentlich auch wieder optimieren kann.
Ich schließe mich der Arbeitsweise von Boris an.
Thematisch mit Kommentarzeilen / Blöcken – erspart das Suchen, vor allem bei tief verschachtelten Klassen. Wobei das Suchen in Zeiten von Firebug ja nun auch teilweise relativ überschaubar ist.
Moin,
klassisch, aber es fängt schon vorher an:
i.d.R. drei CSS-Dateien:
bildschirm/style.css
druck.css
ie.css
Innerhalb der ie.css unterscheide ich nach IE-Version.
Deshalb wird dort fast alles kommentiert.
Zuerst erstelle ich anhand der Seitenarchitektur (Startseite, Anzahl Unterseiten) ein Inhaltsverzeichnis und gleich die Kommentarzeilen für die einzelnen Abschnitte mit ein paar Leerzeilen dazwischen.
Die Struktur ist eigentlich immer gleich:
Allgemeine Selektoren
Allgemeine Hyperlinks
Seitenabschnitte (#kopf, #sidebar, #inhalt, #fuss, etc.)
Unterseiten
Sonstige Klassen (.nachoben, .clear, .skiplink, etc)
Die Deklarationsblöcke sind immer gleich organisiert, in etwa nach dem Boxmodell von innen nach außen:
position, z-index, float, width, height, textsachen, padding, border, margin.
Sehr lange CSS-Dateien sind absolut kein Problem für mich, finde dank der Systematik alles rappzapp wieder.
Noch ein Wort zu großen Bildschirmen:
Habe einen 26er. Die Programme ziehe ich nie horizontal über den ganzen Viewport auf, weil das Lesen durch die längeren Augenbewegungen von links nach rechts auf Dauer zu anstrengend sind.
Der Vorteil eines großen Bildschirms ist imho für einen Webworker, das man mehrere Programmfenster nebeneinanderstellen kann.
) ist das super.
Vor allem bei größeren copy/paste-Aktionen (Wenn der Webworker eins kann, dann ist es copy/paste
Gruß
Klaus
Wie ich mein CSS organisiere? Kommt drauf an. 🙂 Bei kleinen Dateien klassisch mehrzeilig, bei größeren, etwa meinem Blog-Theme, einzeilig, weil’s sonst viel zu unübersichtlich und scrolllastig würde, auch wenn mir mein Editor auf dem Haupt-PC (UltraEdit) alles schön alphabetisch in einer Sprungliste anzeigt.
Dabei sind alle Deklarationen weitgehend thematisch gruppiert, denn bei einer alphabetischen Sortierung blickt man doch nicht mehr durch, wenn das Projekt mal eine gewisse Größe hat. Und die öffnenden Klammern { sind meistens innerhalb eines Blocks untereinander ausgerichtet (mit Tabs). Dazu noch ein paar spärliche Kommentare, und gut ist’s.
Die Schreibweise in einer Zeile finde ich persönlich schlecht les- und wartbar. Mal eben ganz fix Eigenschaften „lesen“ und diese auskommentieren, um einen anderen Style zu probieren, scheitern im Handling. Bei mir im Team hätte das keine Chance.
Das hier als positiv aufgeführte Argument der kleineren oder kürzeren Datei kann ich nicht teilen. Denn in der lokalen Entwicklung liegt der Fokus Nummer 1 auf Wartbarkeit und Lesbarkeit im Team. Sobald eine Version davon online auf den Server hochgeladen werden soll, wird davon automatisch eine komprimierte Version online gestellt. Und nur dort – auf dem Liverserver – ist eine kleine Datei von Vorteil, nicht bei der Entwicklung.
Statt vieler Entwicklungs-CSS in thematischen Bereichen (Basis, Typo, Formulare, Tabellen, Sonstiges…) landet auf den Live-Server ein, maximal zwei komprimierte Dateien.
Achja: Und ich habe übrigens einen 27″-Monitor (iMac) und arbeite dennoch leserlich. Zum einen, weil es meine Präferenz ist, zum anderen, weil ich Links auf dem Monitor den Editor (IDE) habe, rechts den Browser.
Ich bevorzuge die klassische Methode der Übersicht halber.
Wieder so ein Thema, wo jeder eine andere Meinung hat. Meine Vorstellung eines idealen Systems sieht momentan so aus:
Eine Haupt-CSS-Datei, die das Seitenlayout (den “Rahmen”), sowie wichtige Formatierungsklassen (“clear”, “note”, “help”, etc.) enthält.
Die Datei ist dann folgendermaßen aufgebaut:
1. grundsätzliche Tag-Formatierung (Links, Überschriften, Formularfelder)
2. Das Layout (Wrapper, Header, Content, Footer)
3. Formatierungsklassen
Je nach Projektgröße lagere ich dann den CSS-Code für verschiedene Bereiche der Webseite in eigene Dateien aus. So finde ich alles relativ schnell und es ist theoretisch auch möglich, nur den Teil des CSS-Codes zu laden, der auf der aktuellen Seite gebraucht wird (was bei einer riesigen style.css nicht geht).
Im Live-System füge ich dann mit Hilfe von Minify alles on-the-fly zusammen und der User erhält ein komprimiertes Stylesheet.
Zur Formatierung des Codes: mehrzeilig, thematisch geordnet.
Social comments and analytics for this post…
This post was mentioned on Twitter by vlad_perun: #CSS-Code organisieren http://goo.gl/fb/ddqa7 #htmlcss #csstipps…
Ich klatsch einfach alles bunt in einander benutze strg + f und ärgere mich warum ich es nicht sortiere.
Vllt fang ich jetzt damit an.
Danke
Danke für den anregenden Artikel.
Auf einer Zeile sortierte ich meine Stylesheets früher. Mit der Zeit war mir das aber zu unübersichtlich. Der von dir vorgeschlagene Zwitter in dem du Eigenschaften gruppierst, gefällt mir gut. Werde ich mal Gelegentlich testen.
Bei mir wird das Stylesheet nach Art der Parameter geordnet. Zuerst die Layout divs von oben nach unten, danach die Details und am Schluss die Contentformatierung. Grundsätzlich habe ich meine Stylesheets in mehrere Dateien aufgesplittet, damit die einzelnen Teile einfacher Wartbar und austauschbar sind. Auf der Webseite binde ich diese seit kurzem mit minify ein.
Ich kann mich noch daran erinnern, als es noch Adobe GoLive gab. Das hatte eine Funktion, mit der man genau das umschalten konnte. Praktisch, wenn man die klassische Methode verwendet und am Ende der Bearbeitung dann auf einzeilig umgeschaltet hat um Platz zu sparen.
Das sollte es in jedem Editor geben.
Ich halte mich allerdings weiterhin an das klassische Konzept. Mit CSSDOC hab ich mich auch mal befasst, allerdings kann ich dir nur zustimmen, was die Lernkurve und den effektiven Nutzen angeht.
Die Kommentare mögen zwar praktisch und von irgendeinem Programm auslesbar sein, aber leicht anzuwenden ist es bei weitem nicht.
[…] CSS-Code organisieren. […]
Da mir die Ladezeit sehr wichtig ist, benutze ich die einzeilige Variante, ohne Whitespaces. Gerade bei größeren CSS-Dateien lässt sich so einiges an KB einsparen.
#bla{background:#ddd;border:1px solid #ccc;margin:12px;}Stefan