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

@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.

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.

ja, bei pastie kann man auch gut Code unterbringen…

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.

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.

@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…

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

;)

@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?

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.