Codecandies

Das Weblog von Nico Brünjes.

CSS Coding Guidelines I

the doctor
The Doctor. © BBC

Begriffsklärung

Codebespiel: Begrifflichkeiten

h2 { color: #000; }

Nachzulesen beim W3C.

Schreibweisen

Codebespiel: Schreibweisen

h2, #container, .formbox { color: #efe; }

Leerzeichen (Space)

Einrückung

Codebespiel: Einrückung 1

.note {
    border: 1px solid #000;
    color: #ff0000;
    margin-bottom: 10px;
}

Ausnahme: Selektor mit nur 1 Deklaration wird einzeilig geschrieben

Codebespiel: Einrückung 2

.note { border: 1px solid #000; }

Regeln, die sich auf Kindelemente beziehen, werden an der Mutter-Regel ausgerichtet.

Codebespiel: Einrückung 3

.note {
    border: 1px solid #000; 
}
    .note p {
        padding: 4px 2px;
    }

To be continued. Update: Teil 2 ist fertig.

0 Kommentare zu “CSS Coding Guidelines I”

    1. Ich möchte bei der Einrückung der Kindelemente heftigst wiedersprechen. Wenn es mehrere Stufen werden, wird es sehr schnell sehr unübersichtlich.

      Ebenso bei Selektoren mit nur 1 Deklaration, auch die sollten normal notiert werden. Grund: Wenn man das erweitern möchte, muss man es nicht erst umformatieren.

    2. Ganz unabhängig von der Frage, was denn wohl die richtige Notation ist: gibt’s nen Editor, der das mit einem „Format CSS“ Button von alleine macht. Mein Zend Studio interessiert sich für CSS scheinbar einen scheiß und im Textmate siehts merkwürdig aus, wenn man auf den „Bundles -> CSS-> Format CSS“ drückt.

    3. @Dirk Ich möchte Dir bei der Nicht-Einrückung der Kindelemente heftigst widersprechen. 😉 Ich ganz persönlich finde das überhaupt nicht unübersichtlich. Aber ich rücke auch die schließende geschweifte Klammer ebenfalls ein. Das sieht weniger zerrupft aus.

      @ben_ CSSedit bietet die Möglichkeit eigene Regeln zum automatischen Einrücken zu definieren: http://macrabbit.com/cssedit/ (Und auch sonst ein klasse CSS Editor für den Mac).

      Ansonsten finde ich gezielt eingestreute Großbuchstaben nicht unschick. Zumindest kann man ein bisschen mehr Übersichtlichkeit ohne weiteren „Ballast“ in Form von Binde- oder Unterstrichen bei IDs und Klassen erreichen: z. B. #siteSearch oder #navTop

      Ein Ausschnitt aus einem Projekt von mir.

      
      ul#nav1st {
      	position: relative;
      	z-index: 10;
      	top: .4em;
      	clear: both;
      	padding-left: 10px;
      	list-style-type: none;
      	background: #2f485f url(../img/gradient.png) repeat-x center; /*§ie6*/
      	}
      	ul#nav1st:after {content:".";display:block;height:0;clear:both;visibility:hidden;}
      	ul#nav1st {display:inline-block;}
      	* html ul#nav1st {height:1%;}
      	ul#nav1st {display:block;}
      	ul#nav1st li {
      		float: left;
      		}
      	ul#nav1st li a {
      		float: left;
      		color: #fff;
      		font-weight: bold;
      		text-shadow: 0.083333em 0.083333em 0.083333em #333;
      		padding-right: 3px;
      		}
      		ul#nav1st li a span {
      			float: left;
      			padding: 0 10px 0 13px;
      			height: 2.166658em; /* 26px */
      			line-height: 2.166658em; /* 26px */
      			}
      			ul#nav1st li a:hover {
      				text-decoration: none;
      				}
      			ul#nav1st li a:hover span {
      				background: #637687 url(../img/gradient.png) repeat-x center; /*§ie6*/
      				}
      

      So verwende ich beispielsweise das Paragraphenzeichen in Kommentaren um auf IE-Extrawürste in per Conditional Comments eingebundene IE-StyleSheets hinzuweisen.

      Die Reihenfolge der Deklarationen ist noch nicht so hundert pro strukturiert. Aber ich versuche zuerst Angaben zur Positionierung und der Art (block, inline und so) des Elementes unterzubringen. Man liest immer mal wieder von dieser oder jener Sortierung. Aber ich finde das bei den wenigen Angaben nicht sooo wichtig.

      @Nico warum rückst Du nicht per Tab ein?

    4. Oh…

      Die Einrückung ist trotz [pre]-Tag nicht zu sehen und damit ist mein vorheriges Code-Beispiel leider weniger aussagekräftig. (Nico, Vielleicht könntest Du [pre] für Kommentare freischalten. Kann man ja eigentlich nichts mit kaputt machen, oder?)

      Hier das Beispiel in „schön“: http://pastie.caboo.se/200985

      😉

    5. Ich nehme immer englische Bezeichnungen für Klassen und IDs. Und ich koppele diese mit Bindestrich, nicht mit Unterstrich.

    6. Wow, der gesammelte Sachverstand. 🙂

      @ben_: ich arbeite eigentlich ausschließlich mit Textmate, die Einrückungen mache ich selbst so, schon automatisch… „Format CSS“ und „Format CSS Compressed“ haben wir eine ganze zeitlang in Produktion benutzt. Dann wurde es mir aber zu unübersichtlich…

    7. Dirk schrieb

      Ich möchte bei der Einrückung der Kindelemente heftigst wiedersprechen. Wenn es mehrere Stufen werden, wird es sehr schnell sehr unübersichtlich.

      Da hst Du nicht ganz unrecht. Der Teil mit der Organisation des CSS kommt ja noch, aber soviel vorne weg: ich nutze beides. Zunächst werden alle generellen Selektoren abgehandelt, html, body, p, div, ul, li usw. Das mache ich ohne die Kindeinrückung.

      Diese benutze ich jedoch danach, weil ich dann den Dokumentenablauf samt Einrückungen darstelle.

      Das ist ein momentaner Kompromiss, bei dem ich mir auch nch nicht 100% sicher bin. Wir haben bisher mit einem sehr großen CSS gearbeitet, das auf sehr viele Seiten zutraf, da gab es dann sehr viele Kindeinrückungen und es wurde prompt unübersichtlich…

      Mit dem Mittelweg sollten Verschachtelungen tiefer als 4 Elemente aber eigentlich nicht mehr vorkommen.

    8. @Dennis Hab‘ das <pre> nachgetragen jetzt geht’s. Wenn’s mit dem Code pasten nicht klappt: pastebin ist ziemlich cool, wenn man über Code diskutieren will…

      Dein Coding-Stil sieht ein wenig so wie der EndofLine-Style aus, sowas hab ich schon mal bei VB gesehen, aber noch nicht bei CSS. Ein bißchen ungewohnt. 😉

      Leerzeichen statt Tabs ist ein Zugeständnis an Kollegen die mit Linux arbeiten. Das ist eher eine allgemeine Regel, man muss sich halt auf eins festlegen, damit nicht immer alles durcheinander gerät.

    9. oh nicht weitergelesen, LOL,

      ja, bei pastie kann man auch gut Code unterbringen…

    10. was die Kleinschreibung angeht, auch das haben wir gerade für eine weitere Stylesprache bei uns festgelegt: klein und underscores.

      Auch eine Sache, die mehr nach Geschmack geht und wo die Festlegung an sich nötig ist.

      Früher hab ich auch gerne CamelCase gemacht.

    11. Hach, eine Style-Diskussion, über nichts kann man sich besser streiten, da es so extrem persönlicher Geschmack ist. Daher bitte nichts zu ernst nehmen, was ich jetzt schreibe. 🙂

      @Dennis: Bei deinem CSS-Style krieg isch Plack, wie der Kölner so sagt. Das liegt bei mir aber auch eher daran, dass ich von der Programmierung her komme, und gerade der Teil mit den eingerückten closing-braces verursacht mir heftigste Pickel, schon immer, egal in welcher Sprache. Wenn du das in C/C++ machen würdest, würd ich dich schlagen 🙂 Und wenn ich das als CSS in die Hand bekäme und bearbeiten müsste, würd ich es erstmal durch einen Beautifier schicken, sorry, ich halte das wirklich für absolut unleserlich. Fehlendes White-Space, keine ordentliche Struktur, das ist wirklich fies.

      @Gerrit: Machen die Bindestriche in der Kopplung nicht irgendwo Probleme? Ich meine, da gabs mal irgendwas mit. Kann aber auch nur ein Syntax-Highlighting in irgendeinem Editor gewesen sein, was das nicht wollte, bin ich mir nicht mehr sicher.

    12. @Dennis: Danke. Sind ja Ferien. Probier ich mal aus.

    13. @Dirk 😉 Keine Sorge. Ich bin kein Fundamentalist. Und ich komme auch nicht aus der Programmierung.

      Ich verstehe Deine Einwände. Allerdings erachte ich diese für CSS nicht als zwingend und für jedermann uneingeschränkt sinnvoll. Anders als bei Programmiersprachen (CSS hat eigentlich auch nichts mit einer solchen zu tun) gibt es ja keine verschachtelten Funktionen oder ähnliches, sondern ausschließlich CSS-Regeln, die hintereinander weg geschrieben werden.

      Ich könnte mir gut vorstellen, dass Dir gerade folgender Part meines, ohne weitere Optimierungen und spontan eingeworfenen Codefragmentes, auch aufgrund Deines ersten Kommentares, besonders missfiel:

      
      ul#nav1st:after {content:".";display:block;height:0;clear:both;visibility:hidden;}
      ul#nav1st {display:inline-block;}
      * html ul#nav1st {height:1%;}
      ul#nav1st {display:block;}
      

      Das sieht in der Tat nicht sehr schön aus, ist aber ein spezielles eingefügtes Konstrukt, welches ein ordentliches Clearing ohne weiteres Markup und weites gehend browserübergreifend möglich macht. Dieses jedes mal ganz aufzudröseln, erscheint mir persönlich weitaus unübersichtlicher (Ich gebe zu, im gezeigten Beispiel hätte ich wenigstens noch Leerzeichen nach den Doppelpunkten einfügen können). An dieser Stelle möchte ich mich dann auch erstmal Jens’ Stoßgebet anschließen.

      Whitespace: definitiv wichtig. Im Design, wie im Code. Ich tendiere bei meinen letzten Projekten dazu, zusammengehörige Regeln ohne Leerzeile aneinanderzukleben. Solche Regelblöcke sind durch eine Leerzeile getrennt und wiederum in übergeordnete durch Kommentare getrennte Sektionen eingeschlossen.

      Diese Sektionen werden bei mir folgendermaßen ausgezeichnet:

      
      /* @group Header */
      
      ...
      
      /* @end Header */
      

      Diese Schreibweise ist allerdings meinen präferiertem und oben schon verlinkten CSS-Editor CSSedit geschuldet, der mir auf so eine schöne ausklappbare Übersicht bietet: http://img.skitch.com/20080522-gsn1bqsyr72b58kte2hfcswj7n.png (Screenshot)

      Bindestrich/Unterstrich: heutzutage sollte beides kein Problem mehr darstellen. Einige Jahre lang hatte wohl der Internet Explorer Probleme mit IDs, die einen Unterstrich enthielten. Auch waren diese laut CSS1 Spezifikationen nicht erlaubt. Siehe auch dazu einen Artikel aus der Steinzeit vom guten Herrn Meyer: http://devedge-temp.mozilla.org/viewsource/2001/css-underscores/

      Der Unterstrich in Klassen- und ID-Namen war zwar noch in CSS2 nicht erlaubt, aber schon in der Berichtigung (Errata) und in CSS2.1 dann offiziell genehmigt.

      Ich freue mich immer, unterschiedlichste Coding- und Styleregeln kennenzulernen und finde es interessant, wie sich das eigene Verhalten von Job zu Job weiterentwickelt. Mal probiert man was neues aus, verwirft es bei weiteren Projekten aber wieder, mal lässt man Anregungen anderer in den eigenen Stil einfließen.

      Zu guter letzt Jens Meierts Simple Rules for Better Organization and More Efficiency

    14. Hm, eigentlich kann man in Textmate aber doch die Bundles recht komfortabel ändern. Müsste man sich mal was ausdenken….

    15. Ich sage immer noch, dass The Doctor. © BBC dir irgendwie etwas ähnlich sieht.