CSS-Debugging: CSS-Hacks versus Conditional Comments

31.08.2009 10:01 Uhr Vladimir Simović, Alexander Neumann

Trotz Fortschritten beim Internet Explorer wird noch einige Zeit vergehen, bis Webentwickler auf Hacks und Conditional Comments verzichten können.

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 [1] 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 [2] 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 [3]. 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 [4] 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.

CSS-Hacks & Conditional Comments

CSS-Hacks

Wurde kein geeigneter Workaround gefunden? Ist die alternative Vorgehensweise unpraktikabel, oder funktioniert sie nicht wirklich zuverlässig? Dann ist es Zeit, die Keule auszupacken und dem Browser zu zeigen, wer das Sagen hat.

Einer der berühmtesten CSS-Hacks trägt den Namen "Star-HTML-Hack":

* html #inhalt p {font-size: 1.1em;}

Die CSS-Regel interpretiert nur IE 5 und 6, weil nur die Versionen den Stern-HTML-Selektor verstehen. Andere Browser können mit dem Selektor nichts anfangen. Daher ignorieren sie die Eigenschaften und Werte in der CSS-Deklaration.

Das genaue Gegenteil bewirkt der Kind-Selektor-Hack:

html>body #inhalt {width: 45em;}

Hier interpretieren IE 5 und 6 den Selektor nicht und ignorieren deswegen die Deklaration. Browser wie Safari, Firefox, Opera und IE 7 setzen die CSS-Regel um.

Entscheidet sich ein Entwickler für CSS-Hacks, sollte er sie gut dokumentieren. Folgendermaßen könnte eine übersichtliche Dokumentation ausschauen:

/*-------------------- 
*** CSS-Hacks ***
-------------------- */
* html #inhalt { ... } /* Hack für IE <7, weil es ... und weil ...*/ 
html>body #inhalt { ... } /* Die Regel wird vom IE<7 
versteckt, weil ... */

Notiert der Entwickler die Hacks so oder ähnlich, reich garniert mit erklärenden Kommentaren, läuft er nicht in Gefahr – sollte der Kunde zwei Jahre später eine kleine Änderung am Layout wünschen –, dass er mehr Zeit damit verbringt, nach der Ursache des Fehlers (dem alten CSS-Hack) zu suchen, als er für die eigentliche Arbeit benötigt.

Ob ein Entwickler die CSS-Hacks in eine Extra-Datei auslagern oder leicht abgesetzt von den anderen Regeln in der Haupt-CSS-Datei unterbringt, ist Geschmackssache. Der Autor teilt die CSS-Dateien nur für unterschiedliche Ausgabemedien auf: für die Ausgabe am Bildschirm und für die Druckausgabe. Angaben, die sich auf ein Medium beziehen, notiert er in der gleichen CSS-Datei.

Das hat Vorteile gegenüber der Vorgehensweise, die CSS-Regeln nach ihrer "Funktion" in unterschiedliche CSS-Dateien aufzuteilen: typo.css, basic.css, layout.css etc. Zum einen lässt sich dadurch die Größe der CSS-Datei geringfügig kleiner halten, weil die gleichen Selektoren nicht mehrfach anzugeben sind, und zum anderen ist die Anzahl der HTTP-Anfragen beim Aufbau der Website zu reduzieren, weil jede verlinkte Quelle – egal ob CSS, JavaScript oder Bilder – eine zusätzliche Anfrage an den Server bedeutet.

Um die CSS-Datei dennoch übersichtlich zu halten, kann man sich unterschiedlicher Mittel bedienen: Einrückungen, Kommentare und durch den Einsatz von "Dokument-Lesezeichen", die manche Text-Editoren besitzen. Letzteres erlaubt dem Entwickler, auf Dokumentabschnitte mit einem Klick zu springen.

Conditional Comments: Kommentare à la Microsoft

Conditional Comments [5] (CC) sind spezielle aufgebohrte HTML-Kommentare, die nur der Internet Explorer ab der Version 5 interpretieren kann.

Das Conditional Comment:

<!--[if IE 5.5]>
<p>Juten Tach, mein Name ist IE 5.5.</p>
<![endif]-->

fängt an und endet wie ein gewöhnlicher HTML-Kommentar: . Danach folgt eine Bedingung (if ...). Es beginnt der Bereich, den nur der IE 5 bis 7 interpretieren kann. In Beispiel richtet sich die Bedingung explizit an den IE 5.5, und nur er zeigt den eingeschlossenen Quelltext an und setzt ihn um. Anschließend schließt man mit [endif] die Bedingung ab.

Die Conditional Comments lassen sich im Kopfbereich (<head>...</head>) und im sichtbaren Bereich (<body>...</body>) verwenden. Somit kann man zusätzliche Stylesheets einbinden und Anpassungen am (X)HTML-Quelltext vornehmen, die nur der IE interpretiert. Die Kommentare erlauben nicht nur, eine bestimmte IE-Version anzusprechen, Entwickler können durch den Einsatz von Operatoren auch mehrere IE-Releases gleichzeitig bedienen:

<!--[if lt IE 7]>...<![endif]-->

Das obige CC richtet sich an alle Internet Explorer, die kleiner Version 7 sind. Die CC verfügen damit über zusätzliche Operatoren:

[if IE X] = Die Angabe ohne Operator spricht nur eine bestimmte IE-Version an.
[if !IE X] = eine Verneinung ("Wenn nicht IE X, dann ...").
[if lt IE X] = kleiner als IE X.
[if lte IE X] = kleiner oder gleich IE X.
[if gt IE X] = größer als IE X.
[if gte IE X] = größer oder gleich IE X.

Mit den CC-Operatoren können Entwickler präzise unterschiedliche IE-Versionen beeinflussen.

Vor- und Nachteile

Vor- und Nachteile der CSS-Hacks

Zu einem umfassenden CSS-Debugging gehört, sich mit den eigenen Schwächen und potenziellen Fehlern auseinander zu setzen und den Aufbau sowohl des (X)HTML- als auch des CSS-Dokuments zu hinterfragen, bevor man sich entscheidet Workarounds und später CSS-Hacks oder Conditional Comments einzusetzen. Doch was ist besser? Was ist praktikabler und was ist zukunftssicherer?

CSS-Hacks haben den Vorteil, dass man sie direkt in die CSS-Datei schreiben kann. Das gestaltet eine zukünftige Layoutanpassung wesentlich einfacher, insbesondere wenn man mit einer zentralen CSS-Datei arbeitet. Der Vorteil ist allerdings gleichzeitig ein Nachteil. Der Entwickler hat eine CSS-Datei erstellt und bemüht sich, sie "sauber" zu halten. Anschließend "beschmutzt" er die CSS-Datei mit Hacks und setzt den standardkonformen Browsern unnötigen Code vor.

Falls der Entwickler die Hacks in eine zusätzliche CSS-Datei auslagert, lässt sich sein Ergebnis nicht mehr einfach warten, weil er die CSS-Angaben auf mehrere Dateien verteilt und mehrere Dateien bearbeiten muss, um relativ kleine Anpassungen vorzunehmen. Durch die zusätzlichen CSS-Dateien entstehen weitere HTTP-Anfragen, die sich negativ auf die Performance der Website auswirken können. Hinzu kommt, dass sich die selektorbasierten CSS-Hacks in ihr Gegenteil verkehren und dadurch Probleme verursachen können, weil sie nicht immer nur eine Browserversion ansprechen, sondern häufig auch mehrere.

Ein weiteres Problem ist die Vergänglichkeit der CSS-Hacks. Das betrifft vor allem die auf Basis von CSS3-Selektoren, die beispielsweise Opera oder Mozilla ansprechen sollen. Schon in der nächsten Version des Browsers könnte es passieren, dass die Hacks nicht mehr wirken. In der Vergangenheit konnte man an mehreren Fällen die Schwäche der Selektoren-Hacks erkennen. Der weiter oben genannte Star-HTML-Hack spricht nicht nur den IE 5 auf Windows, sondern auch den IE 5 auf dem Mac an – was nicht immer notwendig gewesen wäre, weil der IE 5 auf dem Mac in der CSS-Unterstützung etwas weiter war. Hier musste man darauf achten, dass man den IE für Mac außen vor lässt.

Vor- und Nachteile der Conditional Comments

Die Schwäche der CSS-Hacks, nicht eindeutig eine Browser-Version anzusprechen, sondern eine "Fähigkeit" abzufragen, ist die Stärke der Conditional Comments. Sie können gezielt eine bestimmte Version des IE beeinflussen. Auch wenn es eine neue IE-Version gibt, ändert sich an der Gültigkeit der Abfrage "Wenn du IE 6 bist, dann ..." nichts. Ein weiterer CC-Vorteil ist, dass man die CSS-Datei "sauber" und schlanker hält, weil sie nicht mit CSS-Hacks bespickt ist.

Sicherlich, auch die CC haben Nachteile. Zum einen handelt es sich um eine proprietäre Technik. Dann sind sie in der (X)HTML-Datei zu notieren, was vor allem bei statischen Websites zusätzlichen Aufwand bedeutet. Bei Redaktionssystemen wie WordPress relativiert sich der Nachteil, weil man die Angaben für den Kopfbereich in der Template-Datei header.php notiert.

Empfehlung

Möchte man lediglich IE 5 bis 7 zähmen, setze man Conditional Comments ein. Sind es nicht mehr als zwei bis vier CSS-Regeln, schreibe man sie in den Kopfbereich des (X)HTML-Dokuments:

<!--[if lte IE 7]><style type="text/css">
.quelltext { width: 510px; }</style><![endif]-->
</head>

Das ist performanter, als eine zusätzliche HTTP-Anfrage durch eine CSS-Datei zu generieren. Erst bei mehreren Regeln kommt eine weitere CSS-Datei zum Einsatz, wobei man sich kritisch hinterfragen sollte, ob das wirklich notwendig ist und ob man nicht etwas übersehen hat, das die Fehler verursacht.

Ergebnis der Umfrage darüber, was Webentwickler bevorzugt einsetzen (Abb. 2)

Der Autor hat in seinem Weblog eine Umfrage [6] darüber gestartet, was Webentwickler bevorzugt einsetzen. Das Ergebnis zeigt Abbildung 2. An der Umfrage haben sich nach knapp zwei Monaten rund 170 Webentwickler beteiligt. Mehr als die Hälfte (56 %) bevorzugen Conditional Comments, wenn es darum geht, den IE im Zaum zu halten. Fast ein Viertel setzt sowohl CC als auch Hacks ein. Lediglich rund ein Fünftel nutzt ausschließlich CSS-Hacks.

Vladimir Simovic
ist Geschäftsführer und Gründer der perun.net webwork gmbh [7]. Er ist Autor mehrerer IT-Fachbücher (WordPress, CSS) und hat Webwork-Artikel für diverse IT-Fachzeitschriften verfasst. (ane [8])

URL dieses Artikels:
https://www.heise.de/-787450

Links in diesem Artikel:
[1] http://www.webhits.de/deutsch/index.shtml?webstats.html
[2] http://jigsaw.w3.org/css-validator
[3] http://www.perun.net/2004/07/04/fehlverhalten-von-ie-im-boxmodell/
[4] http://de.wikipedia.org/wiki/Quirks-Modus
[5] http://msdn.microsoft.com/en-us/library/ms537512(VS.85).aspx
[6] http://www.perun.net/2009/06/23/umfrage-css-hacks-vs-conditional-comments
[7] http://www.perun.net/
[8] mailto:ane@heise.de