Navigation überspringen: Zu den neuesten Einträgen oder zu den aktuellen Artikeln .

CSS-Spickzettel

Peter Bergner am 05.12.2003 – 2 Kommentare

Das Original-Dokument “CSS Crib Sheets” (CSS-Spickzettel) von Dave Shea ist eine Liste mit Punkten, die den CSS-Designer bei der Entwicklung und dem Testen seines CSS-Codes unterstützen sollen.

Wie es in der Natur von Spickzetteln liegt, enthält er in stark verkürzter Form Hinweise auf häufige Fehlerquellen, die immer wieder auch in den einschlägigen Mailinglisten nachgefragt und beantwortet werden ;-)

Um allen CSS-Designern diesen “Spickzettel” auch in deutscher Sprache verfügbar zu machen, habe ich mich zu dieser Übersetzung entschlossen. Allerdings war ich an einigen Stellen der Meinung, dass weiterführende Links oder Hinweise ganz hilfreich wären. Diese Anmerkungen und Hinweise wurden von mir in Klammern gesetzt.

Um das Verständnis zu erleichtern, habe ich zusätzlich – und soweit verfügbar – deutschsprachige Quellen angegeben.

[Neu] Wie am Ende dieses Dokuments erwähnt, erweitert und aktualisiert Dave Shea in unregelmäßigen Abständen seinen “CSS Crib Sheet”. Diese Änderungen mache ich in der Übersetzung durch die Phrase [neu] kenntlich.

Bei Mezzoblue, der Webpräsenz von Dave Shea, kann das
Original nachgelesen werden.

Hier folgt die Übersetzung:

CSS-Spickzettel

Verzweifeln Sie nicht, wenn Sie Ihre Website mit CSS gestalten und häufiger mal seltsame Layoutausgaben zu sehen bekommen. Hören Sie auf zu versuchen mit dem Kopf immer wieder durch die Wand zu wollen. Dies ist der Versuch den Gestaltungsprozess zu vereinfachen und dient als Kurzreferenz beim Testen.

Im Zweifelsfall validieren

Beim Debuggen (Überprüfen und Korrigieren) können Sie sich eine Menge Kopfschmerzen ersparen, indem Sie als Erstes einfach Ihren Code validieren. Unsachgemäßes XHTML/CSS ist häufig Ursache für ein fehlerhaftes (“zerschossenes”) Layout. (HTML-Validator, CSS-Validator)

Schreiben und prüfen Sie Ihren CSS-Code in den fortschrittlichsten Browsern, die es gibt, BEVOR Sie in anderen Browsern testen, nicht danach.
Wenn Sie Ihre CSS in “defekten” Browsern (z.B. IE) testen und korrigieren, wird ihr Code auf dem fehlerhaften Rendering dieser Browser zu beruhen. Wenn es an der Zeit ist, in einem standardkonformen Browser (z.B. Mozilla) zu testen, werden Sie frustriert feststellen, dass dieser Browser Ihre CSS “verkehrt” rendert. Stattdessen starten Sie mit dem perfektesten (standardkonformen Browser) und fügen Sie dann die Hacks für die weniger fähigen Browser hinzu. So ist Ihr Code von Anfang an standardkonform, und Sie müssen nicht so viel hacken, um andere Browser zu unterstützen. Zur Zeit unterstützen Mozilla, Safari oder Opera die Standards am besten. (Diesen Punkt hat Dave Shea vom Ende seines Dokuments hierher an den Anfang verschoben, um dessen Priorität zu verdeutlichen)

Überprüfen Sie, ob Ihr gewünschter Effekt tatsächlich existiert.

Es gibt browserspezifische CSS-Erweiterungen, die nicht in den offiziellen Spezifikationen (auf Deutsch) enthalten sind. Wenn Sie mit Filtern und Scrollbar-Formatierungen arbeiten, sollte Ihnen klar sein, dass Sie damit propietären Code verwenden, der nur im Internet Explorer funktioniert. Wenn der Validator Ihnen einmal erklärt, das der von Ihnen verwendete Code “nicht definiert” ist, handelt es sich wahrscheinlich um propietären Code, der nicht crossbrowserkompatibel ist.

Überprüfen Sie bei floatenden Elementen immer die korrekte Anwendung von “clear”.

Die Verwendung von floatenden Elementen ist verzwickt und nicht immer tun sie das, was Sie von ihnen erwarten. Wenn Sie in eine Situation kommen, in der sich ein floatendes Element über das umgebende Container-Element ausdehnt oder sich auf andere Art nicht so verhält wie Sie es erwarten würden, überprüfen Sie, ob das was Sie erreichen wollen, überhaupt machbar ist.
Lesen Sie dazu auch Eric Meyers Tutorial

Zusammenfallende Ränder; “padding” oder “border” anwenden, um dies zu vermeiden

Möglicherweise mühen Sie sich mit zusätzlichen Seitenrändern, die Sie eigentlich nicht wollen oder mit Seitenrändern, die gewünscht sind, aber nicht angezeigt werden.
Wenn Sie Seitenränder mit “margin” formatieren, ist das Überdecken der Seitenränder von (benachbarten) Elementen am wahrscheinlichsten. Andy Budd erklärt detailliert, was beim “margins collapse” passiert und wie Sie es vermeiden können. ( siehe dazu)

Vermeiden Sie die gleichzeitige Angabe von padding/borders UND einer festen Breite für Elemente

Der IE5 geht mit dem Box Model ( siehe auch) so falsch um, das dies zu einiger Verwirrung führt. Es gibt zwar Wege dies zu umgehen, aber es ist besser “padding” auf das Elternelement anstelle des Kindelementes – das eine feste Breite erhält – anzuwenden.

Vermeiden Sie den “Flash of Unstyled Content” (FOUC) im IE

Wenn Sie zum Einbinden Ihrer externen Stylesheets ausschließlich @import verwenden, werden Sie früher oder später feststellen, dass beim Aufruf Ihrer Seite im IE das Dokument kurz unformatiert “aufblitzt”, bevor die CSS-Datei geladen wird. Das kann vermieden werden
(Anmerkung: Dieser Effekt tritt dann nicht auf, wenn vor dem importierten Stylesheet ein weiteres per eingebunden wurde.
Gibt es allerdings keine Styles per einzubinden, z.B. weil man den NS4.x ohne Styles lassen möchte, dann kann man ein leeres Stylesheet mit nur einer Kommentarzeile per einbinden. Für den NS4.x ändert sich dadurch nichts, der FOUC tritt jedoch nicht mehr auf.)

Geben Sie Acht beim Gestalten von Links, wenn Sie Anker benutzen

Wenn Sie in Ihrem Code klassische Anker benutzen, werden Sie feststellen, dass diese auch die :hover- und :active-Pseudo-Klassen verwenden. Um dies zu umgehen, sollten Sie entweder IDs anstatt der Anker benutzen oder die Anker mit der etwas ungewöhnlicheren Syntax :link:hover, :link:active formatieren.

Vergessen Sie nicht das “LoVe/HAte”-Linking

Beim Verwenden von Pseudoklassen für die Formatierung von Verweisen (Links), sollten Sie die Reihenfolge: Link, Visited, Hover, Activ benutzen. Irgendeine andere Reihenfolge wird nicht zuverlässig arbeiten. Sollten Sie außerdem in Betracht ziehen :focus zu verwenden, ändern Sie die Reihenfolge zu LVHFA (Link, Visited, Hover, Focus, Activ). [neu] (oder “Lord Vader’s Handle Formerly Anakin”, wie Matt Haughey vorschlägt). (“LoVe/HAte” dient genauso wie “Lord Vader’s Handle Formerly Anakin” als “Eselsbrücke”.)

Vergessen Sie nicht die “TRouBLEd” Rahmen

Shorthands (Kurzschreibweisen) für Ränder (border), Seitenränder (margin) und Polster (padding) erwarten die spezielle Reihenfolge: Top, Right, Bottom, Left. So ergibt “margin: 0 1px 3px 5px;” einen oberen Seitenrand von 0px, einen rechten Seitenrand von 1px und so weiter.
(Anmerkung: Die Reihenfolge der Wertangaben in Shorthands erfolgt immer im Uhrzeigersinn beginnend mit Top (Oben). Das Wort “TRouBLE” dient als “Eselsbrücke”)

Geben Sie Maßeinheiten für Werte an, die nicht Null sind

CSS erfordert die Angabe von Maßeinheiten für alle Quantitäten (Mengenangaben) wie z.B. Schriftgröße (Fonts), Seitenrändern und andere Größen. Wenn keine Größe angegeben wurde, kann man nicht darauf vertrauen, wie sich die Browser verhalten werden.
(Anmerkung: Der Browser muss “raten”, wenn er nicht gesagt bekommt, ob man nun 12pt, 12px, 12%, 12em oder 12ex meint.)
Null ist jedoch Null, sei es px, em oder irgendetwas anderes. Maßeinheiten sind hier nicht notwendig. Beispiel: padding:0 2px 0 1em;

Prüfen Sie unterschiedliche Schriftgrößen

Fortschrittliche Browser wie Mozilla und Opera erlauben Ihnen, die Textgröße neu zu bestimmen, gleichgültig, welche Maßeinheit Sie benutzen. Einige Benutzer haben mit Sicherheit eine größere oder kleinere Standardschriftgröße eingestellt als Sie; versuchen Sie, dass Ihre Site auch mit der größtmöglichen Schrift nutzbar bleibt.

Teste eingebettet; starte importiert!

Wenn Sie während des Testens mit im HTML-Code eingebetteten Stylesheets arbeiten, werden Sie auch alle möglichen versteckten Fehler entdecken (und korrigieren können). Dies ist besonders beim Arbeiten mit einigen Mac-Browsern sehr wichtig. Sie sollten sich jedoch vor dem Freischalten Ihrer Site versichern, dass Sie Ihr CSS in eine externe Datei ausgelagert und mit @import oder wieder eingebunden haben.

[neu] Einen einfachen Rahmen hinzuzufügen, hilft beim Überprüfen des Layouts

Eine allgemeine Regel wie etwa “div {border: solid 1px #f00;}” kann den Weg verlängern, um ein Layoutproblem herauszufinden. Wird jedoch ein spezielles Element mit einem Rahmen versehen, kann das sehr hilfreich sein, um Überlappungen oder Leerräume festzustellen, die auf andere Art möglicherweise nicht feststellbar wären. (Gemeint ist das temporäre Hinzufügen der Eigenschaft {border: 1px solid red/*oder andere Farbe*/;} zu einem Element, um in der Testphase dessen Ausdehnung sichtbar zu machen).

Benutzen Sie keine Anführungszeichen für Pfade/URLs

Wenn Sie ein Hintergrundbild definieren oder zu importierende Dateien geladen werden sollen, benutzen Sie keine Anführungszeichen zum Einschließen der Pfadangaben. Dies ist nicht notwendig und der IE5/Mac würde dadurch ausgeschlossen.
(Beispiel: Anstatt background-image:url(“ordner/hintergrund.jpg”); schreiben Sie background-image:url(ordner/hintergrund.jpg);)(Abschnitt hierher verschoben)

[neu] Verlinke nicht auf leere Stylesheets als “Platzhalter” für zukünftige Stylesheets (z.B. für Handheld- oder Print-Stylesheets)

Der Mac IE5 “würgt” an an einem leerem Stylesheet herum, was zur Verlängerung der Ladezeit führt. Stattdessen sollte mindestens eine Zeile (es kann auch ein Kommentar sein) eingefügt werden, um das “Herumwürgen” des Mac IE5 zu verhindern.
(Das sollte man übrigens auch beachten, wenn eine leere CSS-Datei benutzt wird, um den sog. FOUC zu umgehen. Einfach in die fouc.css eine Kommentarzeile /* Kommentar */ einfügen.)

Außerdem folgen hier einige wichtige Anmerkungen, die zwar nicht unmittelbar mit der Funktionalität der Dinge (CSS-Datei) zu tun haben, aber beim Entwickeln beachtet werden sollten:

Organisieren Sie Ihre CSS-Datei

Überprüfen Sie die passende Kommentierung von CSS-Blöcken, die Gruppierung ähnlicher Selektoren und die Schaffung einer gleichbleibenden Namenskonvention, die Leerraumformatierung (Empfehlung: einzelne Leerräume anstelle von Tab-Stopps für plattformübergreifende Berücksichtigung benutzen.) und die Reihenfolge von Eigenschaften.
(Anmerkung zur Leerraumformatierung: Dave will damit sagen: verwende lieber ein [oder auch mehrere] Leerzeichen statt eines Tabulatorschritts in der CSS-Quelldatei, weil das auf jedem System gleich dargestellt wird, während die Voreinstellungen für die Tabulatorschrittweite ganz verschieden sein können.)

Benennen Sie Klassen/IDs nach deren Funktion, nicht nach der äußeren Erscheinung

Wenn Sie eine ”.kleinblau”-Klasse anlegen und später die Notwendigkeit besteht die Schrift auf Groß und Rot zu ändern, macht die Klasse(nbezeichnung) keinen Sinn mehr. Benutzen Sie stattdessen beschreibende Klassen wie z.B. ”.copyright” und ”.pullquote”.

Selektoren kombinieren

Die CSS-Dateien möglichst klein zu halten, ist wichtig um Downloadzeiten zu verringern; sooft es möglich ist, sollten Sie Gruppierungen (Deutsch) einsetzen, Selektoren für Nachfahren (Deutsch) nutzen und Redundanzen vermeiden, indem Sie Shorthands (Deutsch.

Beachte die Accessibility (Zugänglichkeit), beim “Image Replacement”

Das klassische FIR (Fahrner Image Replacement) bereitet bekanntlich Probleme in Screenreadern und bei Usern, die mit abgeschalteter Bildanzeige surfen.
Es gibt Alternativen benutze unterschiedliche.

© Copyright 2001-2003, Dave Shea, all rights reserved.
(Übersetzung: 12/2003 durch Peter Bergner)
(Translation: 12/2003 by Peter Bergner)

Ich bedanke mich bei Dave Shea für die Erlaubnis zur Veröffentlichung der Übersetzung und beim CSS-Technik-Team für die kompetenten Hinweise und Ergänzungen ;-)

2 Kommentare

  1. hallo,

    sind ja ein paar mir bis dato unbekannte dinge bei.

    FOUC hatte ich auh mal beim schreiben eines Templates, es gab nur ein globales Stylesheet. Das das der Grund war, weiß ich jetzt erst.

    Klassennamen:

    Ich möchte wiedersprechen, das Klassen immer nach Ihrer Funktion zu benennen sind. Da wo Formatierung struktur-abhängig ist, sollte immer über die Eltern-Elemente formatiert werden.

    Viel zu wenig genutzt wird die möglichkeit der Klassenkombination heutzutage, obwohl das sehr praktisch und Code-reduzierend sein kann. Man kann nämlich beide Formen sehr praktikabel mischen und prima "generisch" das Layout manipulieren unter Einsatz von JS.

    Gerade zu Zeiten des AJAX-Hypes.

    Aber zugegeben, man muss wirklich wissen was man tut und warum.

    Und das Style-Sheet sollte ausreichend die Verwendung solcher Klassen erklären, die dann am besten auch immer einen globalen Charakter erfüllen können, ohne Bruch durch unbeabsichtigte Vererbung.

    Ausserdem bieten einige WYSIWYG-Editoren in CMSystemen, Tiny für Typo3, dem Redakteur die Auswahl von Klassen anbieten. So kann man ihmeine schöne Methode der Formatierung anbieten, ohne das er sich die Styles selbst jedesmal zusammenklickt oder gar fehlerhaftes HTML in die Eingaben schreibt.

    Grüße Dennis

    dennis am 25.03.2008

  2. Schönen Dank für die Übersetzung!

    Es ist jedoch noch ein Fehler enthalten. Bei der Einbindung der Stylesheets, fehlt einige Male das Wort 'link', da der Editor den HTML-Tag rausgeschmissen hat... Die meisten wissen sicher was gemeint ist, aber es ist dennoch unschön...

    so long

    Jens am 12.06.2008

Kommentar hinzufügen

Bitte füllen Sie alle Felder mit einem * aus. Ihre E-Mail-Adresse wird nicht veröffentlicht. HTML ist nicht erlaubt, dafür Markdown.






Zur Spamvermeidung nutzt das Formular ein sogenanntes Captcha.
Bitte tragen Sie das Ergebnis der Rechenaufgabe in das nachfolgende Feld ein.
(Beispiele: max(3,5) = 5; min(2,8) = 2; 3 + 5 = 8)