Requirements from hell: TYPO3 und die Kompatibilität mit IE6

Welcher Webentwickler kennt sie nicht – die kalten Schauer, die einem den Rücken herunterlaufen, wenn man in den Anforderungen zu einem neuen Projekt über diesen unscheinbaren Punkt stolpert: “Kompatibilität mit Internet Explorer 6”. Hier muss definitiv der Teufel höchstpersönlich bei der Erstellung der Anforderungen seine Finger im Spiel gehabt haben! Da kann man nur froh sein, wenn man mit einem umfangreich konfigurierbaren CMS wie TYPO3 arbeitet. Natürlich kann einem ein solches System auch nicht die Arbeit abnehmen, die man in HTML-Template und StyleSheets stecken muss, um Browserkompatibel daherzukommen. Einiges kann aber sehr komfortabel eingestellt werden, um auch ungeliebten Kandidaten wie dem IE6 gerecht zu werden, ohne dabei Validität in anderen Browsern zu verlieren und nicht benötigten Ballast mitzuschleppen, wenn es mal ein guter Browser ist, der die Webseite anzeigen soll. Ein paar solcher Einstellungen sollen im Folgenden gezeigt werden, damit TYPO3-Webseiten auch mit dem IE6 funktionieren.

1. Der Doctype-Switch

XHTML braucht einen XML-Header. Dieser muss – unter normalen Umständen – in der ersten Zeile des Dokumentes stehen, ansonsten wäre das XML nicht valide. Erst dann darf die – ebenso benötigte – Doctype-Definition folgen. Leider verfährt der Internet Explorer – auch in aktuelleren Versionen – mit anerkannten Standards oft in üblicher Microsoft-Manier: Sie werden ignoriert. In diesem speziellen Fall wird der Internet Explorer schlicht und ergreifend in den sogenannten Quirks-Mode geschleudert, wenn die erste Zeile nicht die Doctype-Definition ist, XHTML hin oder her. Die Folge: Die Seite wird wie zu guten alten HTML4-Seiten interpretiert und sieht in aller Regel ziemlich übel aus. TYPO3 bietet von Haus aus eine Option, die aus einem validen XHTML-Dokument ein nicht-vaides, dafür aber IE-kompatibles Dokument zaubert: den Doctype-Switch. Es handelt sich um ein simples Flag, das im CONFIG-Objekt gesetzt werden muss.
Dank der TYPO3-Conditions kann man dieses Flag immer nur dann setzen, wenn der Client auch einer aus dem Hause Microsoft ist. Dazu verwendet man folgendes TypoScript:

1
2
3
4
5
6
7
8
9
10
config {
  baseURL = http://www.example.com/
  xhtml_cleaning = all
  doctype = xhtml_trans
  doctypeSwitch = 0
  # ...
}
[browser = msie]
  config.doctypeSwitch = 1
[global]

Erläuterung: die Option config.doctypeSwitch = 0 schaltet per Default erst mal den Doctype-Switch aus. Das Dokument wird also mit XML-Header in der ersten Zeile valide ausgeliefert. Jetzt kommt der Trick: in der Condition [browser = msie] werden alle Internet Explorer abgefangen. Für diese wird die Option doctypeSwitch dann aktiviert, der XML-Header wird hinter die Doctype-Definition gesetzt. Zwar nicht mehr valide, aber wenigstens kein Quirks-Mode.

2. PNG-Fix

Es gibt eine Vielfalt von Lösungsansätzen, um dem IE6 die korrekte Darstellung von transparenten PNG-Dateien beizubringen. Einige davon funktionieren mit einer .htc-Datei, die das Rendering-Verhalten des Browsers beinflusst. Ein solches Beispiel kann hier heruntergeladen werden.
Die Funktionsweise des Ganzen ist in etwa: Man hinterlegt irgendwo die .htc-Datei und das blank.gif (1px X 1px transparent). Dann wird über die CSS-Eigenschaft behaviour dem Browser gesagt, wie er mit transparenten Elementen umzugehen hat, indem man hier auf die .htc-Datei verweist. Im Code sieht das in etwa so aus:

1
2
3
4
5
<style type="text/css">
img, div, a {
behavior: url(iepngfix.htc);
}
</style>

In der .htc-Datei steht nun eine Menge JavaScript, die letztendlich dazu veranlasst, transparente PNGs mit Hilfe des beiliegendem transparenten GIFs umzubauen, so dass auch der IE6 formvollendete transparente Grafiken darzustellen vermag.
Beim Einbinden einer solchen Lösung kann man allerdings böse Überraschungen erleben, wenn man nicht auf einige Dinge achtet. Eines dieser Dinge ist zum Beispiel das besonders ausgeprägte Sicherheitsbewusstsein des IE6.
Hat man zum Beispiel seine TYPO3-Installation mit einem base-Tag (config.baseURL) konfiguriert, der z.b. auf http://www.example.com/ verweist, iepngfix.htc relativ verlinkt eingebunden und und ruft nun eine Seite unter der Domain http://example.com/ auf, wird man mit Erschrecken feststellen, das iepngfix.htc seinen Dienst versagt. HTC-Dateien werden nämlich nicht von einer fremden Domain geladen. Wer dies versucht, bekommt nur eine Fehlermeldung mit dem sinngemäßen Wortlaut “Access denied”. Die relative Verlinkung von iepngfix.htc in Kombination mit der baseURL ist dasProblem. Der Browser versucht trotz Aufruf von http://example.com/ die Datei von http://www.example.com aufzurufen, also von einer anderen Domain. Das riecht aber nach bösen Aktivitäten, weshalb der zuverlässige IE6 sagt: “Nein, liebe Hacker, ich werde keine browsermanipulierenden Dateien von mir suspekten, fremden Domains laden, ätsch!”. Um das zu umgehen, muss man bei der Einbindung des iepngfix nur folgendermaßen vorgehen:

Zur Installation entpackt man die herunter geladene Datei einfach in das Verzeichnis fileadmin/templates/iepngfix/. Dieses Verzeichnis ist wichtig, da in der .htc-Datei der Pfad zu dem transparenten GIF eincodiert ist. Will man ein anderes Verzeichnis verwenden, muss dieser Pfad in der .htc-Datei angepasst werden. Danach muss man in seinem TypoScript-Setup noch folgende Zeilen eintragen:

1
2
3
4
5
6
7
8
[browser = msie] && [version = < 7.0]
tmp.iepngfixPath = TEXT
tmp.iepngfixPath {
  data = getenv:HTTP_HOST
  wrap = <style type="text/css">img, div, a { behavior: url(http:// | /fileadmin/templates/iepngfix/iepngfix.htc) }</style>
}
page.headerData.10 < tmp.iepngfixPath
[global]

Der Trick ist, das dabei die .htc-Datei nun direkt und absolut eingebunden wird, und zwar mit der aufrufenden Domain (getenv:HTTP_HOST), nicht relativ mit der baseURL. Und das auch nur für IE <= 6.

3. CSS

An dieser Stelle werde ich keine Diskussion über Browserweichen o.ä. lostreten, ich persönlich halte so etwas für lästig und eher unnötig. In meiner gesamten Laufbahn ist mir noch kein Projekt untergekommen, wo verschiedene CSS-Dateien für verschiedene Browser nötig gewesen wären. Wenn man seine StyleSheets bedacht und strukturiert entwickelt und auf merkwürdige Margin- und Padding-Exzesse verzichtet und sorgfältig mit Positionierungen umgeht, wird man auch mit dem IE6 keine Probleme bekommen. Sachen wie negative Margins und wilde Float-Konstrukte, wo sie nicht notwendig sind, weil u.U. eh schon gefloatet wird, sind zu vermeiden Ansonsten empfiehlt es sich grundsätzlich immer mindestens zwei Browser (einer davon der IE6!) beim Entwickeln der StyleSheets geöffnet zu haben.

3. JavaScript

Eigentlich gibt es hier nicht all zu viel zu beachten. Lediglich eine Sache, die man immer erst im IE6 merkt, ist das sehr strenge Interpretieren von JavaScript-Objekten, die man direkt initialisiert. Ein Objekt der folgenden Art

1
2
3
4
var object = {
  attribute1: true,
  attribute2: false,
};

führt im IE6 zu einem Fehler, meistens mit sehr wenig hilfreicher Fehlermeldung.
Dieser Code hingegen funktioniert tadellos:

1
2
3
4
var object = {
  attribute1: true,
  attribute2: false
};

Na, Unterschied gesehen? Das Problem ist das kleine, unscheinbare Komma hinter dem Wert für attribute2. Da hier kein weiteres Element folgt, ist das Komma nicht notwendig und verursacht im IE6 sogar einen kritischen Fehler. Alle anderen mir bekannten Browser sind diesbezüglich wesentlich gnädiger.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.