Informationen zum Debuggen von CSS-Cross-Browser-Style-Fehlern

Als Erstes müssen Sie einen guten Browser auswählen. Meine Wahl fällt auf Chrome, da es über leistungsstarke Debugging-Tools verfügt. Wenn ich mit dem Debuggen in Chrome fertig bin, fahre ich mit dem Debuggen in Safari oder Firefox fort.

Wenn Sie in diesen „guten“ Browsern nicht die erwarteten Ergebnisse erhalten, liegt es wahrscheinlich daran, dass der Code selbst gegen CSS-Regeln verstößt. Anstatt zu versuchen, die Probleme zu umgehen, die bei diesen „guten“ Browsern auftreten, sollten Sie versuchen, die Ursache des Problems zu ermitteln. Normalerweise überprüfe ich die folgenden möglichen Fehlerquellen:

• HTML-Code erklärt – Haben Sie vergessen, ein Tag zu schließen? Umschließen Sie ein Blockelement mit einem Inline-Element? Code, der gegen Standards verstößt, kann von verschiedenen Browsern möglicherweise unterschiedlich interpretiert und dargestellt werden.
• Verwenden Sie das CSS-Lint-Tool, um Ihren CSS-Code zu überprüfen. Achten Sie auf die erkannten Fehler. In den meisten Fällen verursachen Fehler eher Unterschiede zwischen den Browsern als Warnungen.
• Vergessen Sie das Zurücksetzen Ihrer Stylesheets und verlassen Sie sich stattdessen auf die Standard-CSS-Stile des (verschiedenen) Browsers.
• Unterschiede in der Browserunterstützung. Verwenden Sie erweiterte CSS3-Eigenschaften oder HTML5-Elemente? Überprüfen Sie die Browser-Supportdokumentation, um sicherzustellen, dass alle Browser Ihrer Zielgruppe abgedeckt sind. Sie müssen „Feature-Fallbacks“ entwerfen, um ältere Browser zu unterstützen. Stuft beispielsweise einen Schattenrand zu einem Rand herab oder stuft abgerundete Ecken zu einem Quadrat herab.
• Das Hinzufügen von Leerzeichen an Stellen, an denen keine sein sollten, kann dazu führen, dass die Ränder seltsam aussehen.
• Es wird die absolute Positionierung verwendet, es werden jedoch keine vertikalen und horizontalen Offsets festgelegt. In diesem Fall wird das absolut positionierte Element an derselben Position gerendert wie die Position: static. Wenn Sie jedoch versuchen, die oberen, rechten, unteren oder linken Werte zu ändern, „springt“ das Element sofort an die Position relativ zu seinem nächstgelegenen relativ positionierten übergeordneten Element.
• Dabei werden Elemente unterschiedlicher Darstellungsarten auf „ungewöhnliche“ Art und Weise kombiniert. Beispielsweise gibt der W3C-Standard nicht vor, wie eine Tabellenzelle angeordnet werden soll, wenn sie sich neben einem schwebenden Element befindet. Daher ist der auf diese Weise geschriebene Code nicht falsch, kann jedoch Fehler verursachen, die in den verschiedenen Browsern zu unterschiedlichen Rendering-Effekten führen.
• Ob der Platz das Layout beeinflusst. Sie möchten nicht, dass Ihre Typografie von Leerzeichen abhängt.
• Bruchteile von Pixelwerten können in verschiedenen Browsern unterschiedliche Effekte hervorrufen.

Als nächstes kommt der Text

Das Wichtigste, das Sie sich merken sollten, ist, dass der W3C-Standard kein Fehlerverhalten definiert. Wenn Sie sich also nicht an die Spezifikation halten, kann dies in verschiedenen Browsern zu unterschiedlichen Effekten führen. Wenn Sie „seltsame“ Eigenschaften (wie etwa Ränder und Inline-Elemente) kombinieren, kann dies ebenfalls zu Fehlern in verschiedenen Browsern führen.

Anzeige

Für mich ist das Schreiben von CSS die Wahl einer Reise. Sie müssen einige Entscheidungen treffen. Beispielsweise müssen Sie zunächst die Elemente auswählen, die Sie mit den verschiedenen Anzeigemodi verwenden möchten: Block, Inline, Inline-Block und Tabelle. Nachdem Sie Ihre Auswahl getroffen haben, können Sie mithilfe bestimmter Methoden die tatsächliche Anzeige ändern.

Blockelemente sollten Ränder, Polsterungen, Höhen und Breiten verwenden. Die Zeilenhöhe gilt jedoch nicht.

Inline-Elemente sollten Zeilenhöhe, vertikale Ausrichtung und Abstand verwenden. Ränder, Abstände, Höhen und Breiten gelten jedoch nicht.

Erstens haben Tabellen eine vertikale und horizontale Ausrichtung. Zweitens: Wenn in der Tabelle ein Element fehlt, kann die gesamte Tabelle merkwürdig aussehen. Schließlich gilt der Rand nicht für Tabellenzeilen und -spalten und die Polsterung gilt nicht für Tabellen oder Tabellenzeilen.

Positionierung

Wenn Sie Elemente auf Blockebene verwenden möchten, müssen Sie als Nächstes eine Positionierungsmethode auswählen:

• Float – Wenn Sie Float verwenden, wird das Element zu einem Element auf Blockebene und die zuvor auf das Element angewendeten Eigenschaften „Vertical Align“ und „Line-Height“ werden ungültig.
• Absolut – Offsets werden relativ zum nächstgelegenen relativ positionierten übergeordneten Knoten berechnet. Absolut positionierte Elemente verursachen keinen Neufluss, wenn sich ihre übergeordneten und gleichgeordneten Knoten ändern. Diese Funktion ist zum Erstellen von Animationseffekten nützlich. Wenn jedoch absolute Positionierung verwendet wird und sich der Inhalt dynamisch ändert, kann es zu Anzeigeproblemen kommen. Ein typisches Beispiel ist eine absolut positionierte abgerundete Box.
• Statisch – Die standardmäßige Positionierungsmethode.
• Fest – Die Position des Elements ist relativ zum Browserfenster. Wird nicht oft verwendet.
• Relativ – Hat normalerweise keinen Einfluss auf den Stil dieses Elements. Nur die untergeordneten, absolut positionierten Kindknoten werden relativ zu diesem Knoten versetzt.

Ich werde hier nicht alle Anzeige- und Positionskombinationen auflisten. Zusammenfassend sind zwei Dinge zu beachten:

1. Sind andere Eigenschaften (wie Ränder und Zeilenhöhen) für die von mir gewählten Anzeige- und Positionierungsmethoden geeignet?
2. Sind die Positionierungsmethoden der Geschwisterknoten konsistent?

Ist es beispielsweise sinnvoll, Float-, Tabellenzellen- und Inline-Elemente zu kombinieren? Wie wird der Browser die Darstellung interpretieren? Gibt es eine Definition im W3C-Standard? Andernfalls besteht das Risiko von Cross-Browser-Fehlern. Natürlich ist eine solche Kombination nicht unmöglich, aber Sie müssen genau überlegen, warum Sie dies tun möchten, und genügend Cross-Browser-Tests durchführen.

Internet Explorer

Nachdem Sie die Probleme mit den „guten“ Browsern gelöst haben, ist es Zeit, auf die IE-Plattform umzusteigen. Ich empfehle, mit der ältesten IE-Version zu beginnen, die Sie unterstützen möchten, da viele Probleme älterer IE-Versionen auch auf neuere Versionen übertragbar sind.

Auch beim Internet Explorer sollten Sie versuchen, das Problem zu isolieren, anstatt sich auf Hacks zu verlassen. Die blinde Verwendung des *- und _-Hacks ist so, als würde man einer Funktion, die einen falschen Wert zurückgibt, ein Fixup (siehe unten) hinzufügen, anstatt den algorithmischen Fehler zu identifizieren.

Natürlich ist es manchmal notwendig, in IE6 und IE7 Hacks zu verwenden. Für IE8 werden Hacks normalerweise nur verwendet, wenn CSS3-Kompatibilität erforderlich ist. Normalerweise sind die Stellen, an denen Hacks in IE6/7 erforderlich sind, die folgenden:

• hat ein Layoutproblem, verwenden Sie zoom:1
• Relative Positionierung führt zum Verschwinden von Elementen
• 3px schwebender BUG
• Schwebefehler von gestreckten Containern werden oft versehentlich durch overflow:hidden maskiert.

Es gibt auch einige weniger häufige Situationen, in denen Hacks erforderlich sind, z. B. wenn sich zwischen zwei schwebenden Elementen ein Kommentarcode befindet, der den Fehler „Duplicate Content“ auslöst. Bei CSS-Problemen, die nur im Internet Explorer auftreten, rate ich Ihnen, genau zu beschreiben, was Sie sehen, und bei Google nach der entsprechenden Lösung zu suchen. Verwenden Sie Hacks nicht blind, um einen Fehler zu vertuschen, bevor Sie die Ursache dafür gefunden haben. Die integrierten Debugging-Tools des Internet Explorers sind furchtbar. Daher müssen Sie dem Element möglicherweise eine Hintergrundfarbe hinzufügen, damit Sie das tatsächliche Layout auf der Seite leichter erkennen können.

Implementierung der Lösung

Wenn Sie die Ursache des Fehlers gefunden haben und wissen, wie Sie ihn beheben können, sollten Sie auch wissen, wie Sie den Code ändern können, ohne vorhandenen Code zu zerstören, der ordnungsgemäß funktioniert. Hier sind meine Vorschläge:

1. Abhängige Stilkaskadierung

2. Browserspezifische Präfixe verwenden

3. Verwenden Sie * und _ für IE6/7

4. Verwenden Sie \9 nicht für IE8

5. Wissen, wann man IE-Hacks aufgeben sollte

6. Verwenden Sie keine Hacks für die neuesten Versionen von Firefox, Chrome, Safari

1. Abhängige Stilkaskadierung

Versuchen Sie zunächst, sich wann immer möglich auf die Stilkaskade zu verlassen. Browser übernehmen immer den zuletzt deklarierten Stil, den sie verstehen können. Daher sollten Sie mit dem Schreiben von Stilen für ältere Browser beginnen, damit der Browser die letzten Stile lesen und verwenden kann, die er versteht. Zum Beispiel:

2. Browserspezifische Präfixe verwenden

Verwenden Sie browserspezifische Präfixe, insbesondere für Eigenschaften, die noch nicht weit verbreitet sind. Zum Beispiel:

Beachten Sie, dass dieser Code zwei Syntaxen für unterschiedliche Versionen von WebKit enthält. Die Reihenfolge der Präfixcodes sollte auch ab den alten Browserversionen geschrieben werden (siehe erste).
Wenn eine Syntax durch einen W3C-Standard definiert ist, sollten Sie diese ans Ende setzen (wie beispielsweise die letzte Zeile im obigen Code). Auf diese Weise wird Ihr Code robust sein, wenn die Browser beginnen, die Standardsyntax für diese neuen Funktionen zu unterstützen.

3. Verwenden Sie * und _ für IE6/7

Beheben Sie Fehler, die speziell bei älteren IE-Versionen auftreten, mit den Tasten * und _. Zum Beispiel:

Alle IE-Hacks zielen auf eine bestimmte Version und alle vorherigen Browser ab, beispielsweise:

_ Für IE6 und früher

* Für IE7 und früher

\9 für IE8 und früher (beachten Sie, dass IE9 auch auf diesen Hack einiger CSS-Eigenschaften empfindlich reagiert)

Daher sollte auch mit dem Schreiben des Hack-Codes für alte Browserversionen begonnen werden (siehe erster Punkt).

4. Verwenden Sie \9 nicht für IE8

Ich würde niemals \9 verwenden, um Styling-Fehler in IE8 zu umgehen. Ich würde \9 nur als „Fallback“ verwenden, um die Browserunterstützung auszugleichen. Ich habe beispielsweise Box-Shadow verwendet (was in fortgeschritteneren Browsern gut funktioniert), aber es sah in IE8 hässlich aus, daher habe ich \9 verwendet, um einen neuen Rahmen hinzuzufügen. Diese Situation kann nicht durch die Stilkaskade (siehe erstes Element) behandelt werden, da hierdurch ein neuer Stil hinzugefügt und kein vorhandener Stil geändert wird.

5. Wissen, wann man IE-Hacks aufgeben sollte

Versuchen Sie nicht, im Internet Explorer genau denselben Effekt zu erzielen. Sind Sie bereit, zusätzliche HTTP-Anfragen und komplexe HTML-/JS-/CSS-Codefragmente zu verschwenden, nur um in IE6-8 denselben Effekt mit abgerundeten Ecken zu erzielen? Für mich persönlich lautet die Antwort „nein“.

Sie sollten wissen, wann Sie einen Hack für eine Funktion aufgeben sollten. Verwenden Sie beispielsweise keine Filter, um Farbverlaufseffekte in CSS3 zu simulieren, da dies zu Leistungsproblemen und typografischen Fehlern führen kann. Der einfachste Ansatz besteht darin, nicht zu erwarten, dass sich Ihre Seiten in allen Browsern genau gleich verhalten. Für Benutzer von IE 6–8 besteht der beste Ansatz darin, ihnen eine vereinfachte Benutzererfahrung zu bieten (beachten Sie: vereinfacht, nicht unvollständig).

Der folgende fehlerhafte Code verwendet Filter, um CSS3-Farbverläufe zu simulieren:

6. Verwenden Sie keine Hacks für die neuesten Versionen von Firefox, Chrome, Safari

Bei Stilfehlern in Firefox, Chrome und Safari sollten Sie am besten sorgfältig prüfen. Es ist sehr wahrscheinlich, dass dies daran liegt, dass Ihr Code gegen die CSS-Regeln verstößt.