CSS-Debugging: CSS-Hacks versus Conditional Comments
Trotz Fortschritten beim Internet Explorer wird noch einige Zeit vergehen, bis Webentwickler auf Hacks und Conditional Comments verzichten können.
- Vladimir Simović
- Alexander Neumann
Auch wenn die meisten Browser weitgehend standardkonform sind und der Internet Explorer 8 in vielen Bereichen zu ihnen aufgeschlossen hat, wird noch einige Zeit vergehen, bis Webentwickler auf Hacks und Conditional Comments verzichten können. Zumindest auf die, die frühere IE-Versionen ansprechen.
Schaut man sich die Webstatistiken von webhits.de an, sieht man, dass heute noch (August 2009) knapp 60 Prozent der Nutzer IE7, IE6 oder kleiner einsetzen. Bis der Anteil auf eine zu vernachlässigende Größe sinkt, fließt wahrscheinlich noch viel Wasser den Rhein hinunter. Webdesigner stehen noch länger vor der Situation, dass ein oder mehrere Browser aus der Reihe tanzen. Häufig ist der Browser aus dem Hause Microsoft der Übeltäter. Bevor man über den Einsatz von CSS-Hacks oder Conditional Comments nachdenkt, gilt es, sich kritisch mit der eigenen Arbeit auseinander zu setzen.
Workarounds
Browser können sich nicht wehren, daher ist es einfach, die Schuld bei ihnen zu suchen. Lieber sollte der Entwickler prüfen, ob er nicht verantwortlich für den Fehler ist. Ist eventuell eine Eigenschaft falsch geschrieben? Hat er ein abschließendes Semikolon bei einer CSS-Deklaration vergessen? Wurde nach der Eigenschaft ein Punkt statt des Doppelpunkts notiert? Solche Flüchtigkeitsfehler lassen sich mit dem CSS-Validator des W3C finden. Liegen sie nicht beim Entwickler, dann ist zu schauen, ob er das Problem nicht mit einem CSS-Workaround oder alternativen Vorgehensweisen lösen kann.
Eine häufige Fehlerquelle ist die fehlerhafte Interpretation des Boxmodells. Das W3C-Boxmodell geht davon aus, dass die Angaben zum Padding (innerer Abstand), Rahmen und Margin (äußerer Abstand) zum Content (Inhalt) beziehungsweise zur Angabe der Höhe und der Breite des Inhalts zu addieren sind. Der Internet Explorer in den Versionen 5 und 6 setzt das Box-Modell anders um. Er addiert lediglich die Margin-Angabe zur gesamten Breite und Höhe. Die Angaben zum Padding und für die Rahmen sind vom Wert für die Breite und Höhe abzuziehen. Bevor man jetzt zu Hacks greift, kann ein Entwickler zumindest dem IE 6 die richtige Interpretation des Boxmodells beibringen, und zwar durch den Einsatz des richtigen Doctyps. Folgende DTDs (Document Type Definitions) bringen den IE 6 in den Standardmodus:
HTML 4.01:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
XHTML 1.0:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1:
<!DOCTYPE html PUBLIC "-//W3C//DTDXHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
HTML 5:
<!DOCTYPE html>
Allerdings ist darauf zu achten, dass man auf die Angabe der XML-Deklaration verzichtet:
<?xmlversion="1.0" encoding="UTF-8" ?>
Die XML-Deklaration muss der Entwickler am Anfang (noch vor der DTD) des XHTML-Dokuments notieren. Sie ist zuständig, den XML-Parsern die Information weiterzugeben, dass das Dokument XML-gerechte Daten enthält und welchen Zeichensatz man verwendet. Das Problem der Deklaration ist allerdings, dass sie den IE 6 vom Standard- in den Quirks-Modus versetzt, was dazu führt, dass der Browser das Box-Modell fehlerhaft interpretiert. Liefert man die XHTML-Dokumente lediglich als Text- oder HTML-Datei aus, kann der Entwickler die XML-Deklaration getrost weglassen.
