>> clean styles

Das schöne an CSS ist, dass es möglich ist, auch noch dem allerletzten Element eine spezielle Auszeichnung mit zu geben. Aber: Spätestens nach der Definition von 300-CSS-Stilen beginnt es unübersichtlich zu werden. Immer. Ein paar kleine Tipps, wie der Durchblick trotzdem gelingt: …

>> Haufen bilden!

Irgendwann sind die Codemonster ganz einfach da: Hier eine kleine Farbanpassung, dort eine Einrückung um drei Pixel und eine um 0.2 Prozent angepasste Fontgröße. Alles schaut gut aus, aber bei der Projektpräsentation findet der Kunde, das Blau könnte ein wenig blauer sein. Klar, kein Problem, ein Farbwert ist schnell angepasst. Aber wo stand der nur?

Spätestens dann ist es nützlich, die Style inhaltlich zu sortieren. Layout zu Layout, die Typografie in eine eigene Kiste, die Formulardefinitionen in eine andere. Und am besten fängt man gleich zu Beginn auch damit an.

So in etwa:

/* layout
----------------------------------------------- */

/* typography
----------------------------------------------- */

/* forms
----------------------------------------------- */
(...)

Und wo wir schon mal dabei sind können wir ja auch Subkategorien bilden – für Header, Sidebars, Footer, den Contentbereich.

Eine andere Möglichkeit ist, separate Stylesheets für jeden Bereich zu erstellen und diese dann mit …

@import url("layout.css");
@import url("typography.css");
@import url("forms.css");

… zu importieren.

>> left rules!

Die Übersicht wird noch besser, wenn alle Selektoren isoliert am linken Rand stehen. Also statt einer Textwüste …

h4{font-weight: bold;padding-bottom: 1.5em;}
h5{font-weight: normal;font-size: 1.5em;padding-bottom: 0;}

… eine saubere, zeilenweise Anordnung wie hier:

h4 {
        font-weight: bold;
        padding-bottom: 1.5em;
        }
h5 {
        font-weight: normal;
        font-size: 1.5em;
        padding-bottom: 0;
        }

Wer sich im Übrigen immer gefragt hat, wozu die TAB-Taste dient: Das war eine Anwendung.

Und es ist auch hilfreich, zusammengehörende hierarchische Tags auch nacheinander zu definieren – wie zum Beispiel hier:

#header {}
#header .logo {}
#header .logo img {}

Eigenschaften, die zum Testen getoggelt werden, muss man nicht immer vollständig ersetzen oder umfangreich auskommentieren – wir machen uns zu Nutze, dass ein fehlerhaftes Tag schlicht nicht interpretiert wird. Aus "border" ist schneller "yborder" gemacht als ein Kommentar geschrieben …

>> comments, please!

Eine gute Idee ist es, den (X)HTML-Code mit Kommentaren zu versehen. Eine bessere Idee ist es, diese nicht nur zu Beginn eines Abschnittes zu setzen, sondern auch zum Ende:

<div id="content">
	<h2></h2>
	<p></p>
	<p></p>
	<p></p>
	<p></p>
</div>

2 Thoughts.

  1. Wenn eine natürlich ein Programm namens gehLeben (GoLive) ;) hat, braucht sich um eine lesbare Codierungstruktur nicht zu kümmern.

    Allerdings sollten Knechte und Mägde anderer Web-Programme oder gar Texteditoren namens vi oder emacs darauf achten – wobei selbst diese schon über Formatierungsmöglichkeiten verfügen.

    Aber du hast Recht, es ist wirklich sinnvoll, sich über eine Ordnung vorger Gedanken zu machen.

    Mit drachlichem Gruß
    Gwendragon

    PS: C'est drôle la vie.

  2. Ooops, GoLive, gibt es das denn überhaupt noch? Bei der CS3 war es jedenfalls nicht dabei …

    Ich habe lange Dreamweaver benutzt und bin inzwischen mit Aptana ziemlich glücklich (OpenSource, Eclipse-basiert mit der Möglichkeit, sich zwecks Anpassung und Erweiterung aus dem vollständigen Eclipse-Fundus zu bedienen).

    Was mich überzeugt hat:

    – Codeassist für alles was ich brauche
    – integriertes Validierungstool
    – mächtiger Debugger
    – Integration diverser AJAX-Frameworks ab Werk
    – Erweiterungsmöglichkeit auf PHP
    – eingebaute Ruby-Entwicklungsumgebung

    Bedeutet allerdings auch, seinen Code selbst zu schreiben und nicht vordringlich auf visuelle Werkzeuge zu setzen.

    Schau mal rein (www.aptana.com), lohnt sich.

    Lucina.

Deine Meinung?