http://jendryschik.de

UX, Usability und Webstandards

Suche
SucheMenü

Browserkompatibilität

Hinweis: Diese »Einführung in XHTML, CSS und Webdesign« ent­spricht der zwei­ten Auf­lage des gleich­na­mi­gen Buches, das im Dezem­ber 2008 im Ver­lag Addison-Wesley erschie­nen ist. Die Inhalte sind mittlerweile veraltet, fast alles hat sich weiterentwickelt. Seit einigen Jahren gibt es HTML5, von XHTML redet niemand mehr, und auch die Entwicklung und Unterstützung von CSS ist um Einiges weiter. Auch fast alle Grundlagentexte müsste man schon lange fortschreiben. Falls Sie die Texte dennoch lesen möchten, behalten Sie das bitte im Hinterkopf.

Zurück zur Startseite und zum Inhaltsverzeichnis des Buchs

Die Unterstützung vieler CSS-Eigenschaften lässt heute leider noch zu wünschen übrig. Dabei sind es nicht die alten, heute überholten Browsergenerationen, die die meisten Probleme bereiten, denn sie verdienen aufgrund ihrer geringen Verbreitung keine Beachtung mehr und machen es ziemlich einfach, CSS vor ihnen zu verbergen. Problematisch sind fehlerhafte Browser mit großer Verbreitung, vor allem der Internet Explorer 6, der immer noch – je nach herangezogener Statistik – von 40 bis 50 Prozent aller Nutzer verwendet wird. Würden Webautoren nur die Teile von CSS verwenden, die auch der IE 6 versteht, bewegten sie sich irgendwo zwischen CSS 1 und CSS 2.

Dieser Abschnitt hilft Ihnen, mit gängigen Browserproblemen zurechtzukommen.

Zum Seitenanfang

Browserunterstützung

In der Praxis kann das Zusammenspiel zwischen verschiedenen Elementen und Eigenschaften einen nicht zu unterschätzenden Einfluss auf die Darstellung haben. Fehler treten oft erst durch das Zusammenwirken mehrerer Eigenschaften an unterschiedlichen Elementen auf.

Aufgrund der rasanten Entwicklung am Browsermarkt und der Vielzahl der verfügbaren Browser ist es nicht möglich, alle Eigenschaften auf jedem Browser in jeder Version durchzutesten – es ist vielmehr davon auszugehen, dass es mittlerweile neue Versionen der getesteten Browser gibt, in denen die beschriebenen Fehler nicht mehr auftauchen, wenn Sie dieses Buch in der Hand halten. Ich habe mich auf die in Tabelle 6.20 aufgeführten Browser beschränkt. Dennoch erheben die Tests keinen Anspruch auf Vollständigkeit; sie sind vielmehr lediglich als kleine Hilfestellung zu verstehen – wenn Sie kritische Eigenschaften und Werte verwenden, sind eigene Tests unumgänglich!

Tab. 6.20: Browser, deren CSS-Fähigkeiten für diese Einführung getestet wurden
Symbol Browser Kürzel
Internet Explorer 6 IE 6
Internet Explorer 7 IE 7
Internet Explorer 8 IE 8
Firefox 3
Opera 8, Opera 9, Opera 9.5
Safari 3
Konqueror 3.5, Konqueror 4

Zum Seitenanfang

Doctype Switching

Viele Webseiten sind noch für vor einigen Jahren aktuelle, heute allerdings nur noch sehr selten verwendete Browser wie die 5er-Versionen des Internet Explorers geschrieben. Diese Browser zeigen jedoch an vielen Stellen eine mangelhafte und nicht standardkonforme CSS-Umsetzung. Ganz gleich, ob Entwickler sich der Fehler als solche bewusst waren, es blieb ihnen nichts anderes übrig, als Webseiten entgegen den Standards auf diese Browser hin zu konzipieren, um das gewünschte Layout umzusetzen. Das führte dazu, dass Webseiten auf damals aktuellen Browsern wie gewünscht aussahen; in heutigen modernen Browsern jedoch würden sie zwar standardkonform, aber falsch im Sinne der ursprünglichen Layoutvorstellungen des Designers dargestellt.

Quirks und Standards Compliance Mode

Die Browserhersteller mussten damit rechnen, dass niemand aktuelle Browserversionen verwenden würde, wenn alte Webseiten darin nicht mehr wie gewohnt aussähen. Daher wurden zwei unterschiedliche Darstellungsarten eingeführt: Der erste Modus, bekannt als Quirks Mode oder Compatible Mode, stellt eine Webseite wie alte, inkompatible Browser dar; der zweite Modus, bekannt als Standards Compliance Mode, bemüht sich um eine Darstellung gemäß den W3C-Empfehlungen. Darüber hinaus unterteilen aktuelle Gecko- und Opera-Versionen den letzten Modus in einen Almost Standards Mode und einen Full Standards Mode.

Der Internet Explorer 8 verfügt ebenfalls über drei Darstellungsmodi: Der Quirks Mode stellt eine Webseite wie alte, inkompatible Internet Explorer dar; dabei entspricht der Quirks Mode des IE 8 dem des IE 7. Daneben verfügt der IE 8 über zwei standardkonforme Modi: einen herkömmlichen IE 7-Standards-Modus, der dem des IE 7 mit all seinen Fehlern entspricht, und einen neuen (IE 8-)Standards-Modus, der die stark verbesserte, komplett erneuerte Rendering Engine des IE 8 verwendet.

Die technischen Details der Umsetzungen sind in den Browserdokumentationen zu finden.

Microsoft und die Mozilla-Entwickler haben sich entschieden, über die Dokumenttyp-Deklaration zu differenzieren. Andere Browser zogen nach. Die Unterscheidung funktioniert in Firefox, Safari und Opera nach folgendem Schema: Wenn das Dokument keine Dokumenttyp-Deklaration hat oder eine aus einer Positivliste, dann gehe in den Quirks Mode. In allen anderen Fällen gehe in den Standards Compliance Mode.

Im Internet Explorer sieht die Regel im Allgemeinen so aus: Wenn die erste Zeile nicht mit einer Dokumenttyp-Deklaration beginnt, die in der Positivliste steht, gehe in den Quirks Mode, es sei denn, es wurde ein Systembezeichner angegeben.

Dieses Verfahren wird Doctype Switching oder Doctype Sniffing genannt.

Die einzelnen Browser entscheiden nach folgenden Regeln, mit welchem Darstellungsmodus sie eine Webseite darstellen:

  • Der Internet Explorer 6 schaltet in den Quirks Mode, wenn keine Dokumenttyp-Deklaration angegeben wird, ebenso bei HTML 4 und 4.01 bei Angabe der Transitional- und Frameset-DTD, wenn kein System Identifier angegeben wird. In allen anderen Fällen, also auch bei allen XHTML-Dokumenttyp-Deklarationen, schaltet IE 6 in den Standards Compliance Mode.

    Leider zeigt sich an dieser Stelle wieder einer der vielen IE-Bugs: Der Internet Explorer erwartet die Dokumenttyp-Deklaration immer in der ersten Zeile des Dokuments. Wenn zum Beispiel eine XML-Deklaration ein XHTML-Dokument einleitet, rendert der IE im Quirks Mode. Da die XML-Deklaration bei XHTML-Dokumenten nicht vorgeschrieben ist, lassen Webautoren sie aus diesem Grund häufig weg. Der Artikel [Silver 2006] führt eine Tabelle auf und dokumentiert die Unterschiede zwischen Quirks und Standards Compliance Mode.

  • Der Internet Explorer 7 verhält sich so wie der IE 6, allerdings haben die Microsoft-Entwickler den XML-Deklaration-Bug behoben.

  • Der Internet Explorer 8 fällt seine Entscheidung über den Darstellungsmodus analog zu seinem Vorgänger. Allerdings verfügt er über zwei standardkonforme Modi. Webautoren haben die Möglichkeit, über ein meta-Element anzugeben, welchen der beiden Modi sie auf ihrer Website angewendet wissen wollen, den IE 7-Standards-Modus oder den IE 8-Standards-Modus. Das meta-Element sieht wie folgt aus: <meta http-equiv="X-UA-Compatible" content="IE=8" />, wobei der Wert des content-Attributs entweder IE=7 oder IE=8 lautet.

  • Opera verhält sich so wie der Internet Explorer ab Version 7. [Opera] führt die Unterschiede zwischen beiden Modi auf.

  • Komplizierter wird es bei Firefox-Browsern. Die aktuellen Versionen unterscheiden nur bei Dokumenten, die mit dem MIME-Typ text/html ausgeliefert werden, zwischen verschiedenen Modi. Dokumente, die als application/xhtml+xml oder mit einem anderen XML-MIME-Typ ausgeliefert werden, werden immer im Standards Compliance Mode dargestellt. Weitere Informationen und eine ausführliche Übersicht dazu, wann in den Quirks und wann in den Full Standards oder Almost Standards Mode geschaltet wird, finden Sie in den Artikeln [Baron 2004] und [Trebing 2002].

Fragwürdiges Konzept

Aufgrund der Fehler, die Browserhersteller in der Vergangenheit gemacht haben, war eine Einführung unterschiedlicher Darstellungsmodi unumgänglich. Ob es sinnvoll ist, gerade über Art und Notation der verwendeten Dokumenttyp-Deklaration den Darstellungsmodus für ein Dokument festzulegen, ist sehr umstritten. Schließlich ist diese Art der Differenzierung alles andere als intuitiv. Die HTML 4-Empfehlung des W3C etwa ist ein standardkonformes Dokument, dennoch wird es nur im Quirks Mode dargestellt. Man kann durchaus bezweifeln, dass die Autoren dieser Website damit gerechnet haben, dass die Darstellung dieses Dokuments in einem Modus erfolgt, der die standardkonforme Darstellung umgeht und dessen Rendering Engine mit voller Absicht an der einen oder anderen Stelle fehlerhaft ist.

Empfehlung

Uns Webautoren bleibt nichts anders übrig, als das Beste aus diesen Voraussetzungen zu machen. Ich persönlich arbeite ausschließlich im Standards Compliance Mode. Mit Fehlern haben Webautoren in allen Modi zu kämpfen, aber wenn Sie im standardkonformen Modus arbeiten, wissen Sie wenigstens, dass die Browser daran schuld sind und nicht Sie – und die Fehler, die auftreten, sind in den meisten Fällen verhältnismäßig einfach zu beheben oder zu umgehen.

Zum Seitenanfang

Der Grund für viele IE-Bugs: hasLayout

hasLayout ist ein proprietäres Konzept (siehe [Chao, Rudel 2007]) des Internet Explorers bis zur Version 7, das bestimmt, wie Elemente ihren Inhalt darstellen, wie sie mit anderen Elementen interagieren und wie sie auf Anwendungs- oder Benutzeraktionen reagieren und sie übertragen. Einige Elemente haben von sich aus »Layout«, bei anderen ist es erforderlich, eine CSS-Eigenschaft anzuwenden, die »Layout« für das fragliche Element verursacht.

Das hasLayout-Konzept stellt Webentwickler vor eine Vielzahl von Problemen. »Layout« hat ungewöhnliche und schwer vorhersehbare Auswirkungen auf die Darstellung von Boxen – und ebenso Folgen für deren Nachfahrenelemente. Ob ein Element »Layout« hat (oder auch nicht), kann unter anderem Folgendes nach sich ziehen:

  • Viele Fehler im Zusammenhang mit Floatierung (siehe Kapitel 7.6 »Ausrichtung und Elementfluss«) treten auf, weil ein Element nicht »Layout« hat.
  • Die betroffenen Boxen behandeln Eigenschaften vollkommen unterschiedlich, abhängig davon, ob sie »Layout« haben oder nicht.
  • Verschiedene Probleme bei der Darstellung von Listen, dem Positionieren von Hintergrundbildern und beim Einsatz von Scripts hängen mit »Layout« – beziehungsweise dessen Fehlen – zusammen.

Folgende Elemente haben von sich aus »Layout« (nicht alle davon werden im Rahmen dieser Einführung behandelt):

  • html, body
  • table, tr, th, td
  • img
  • hr
  • input, button, select, textarea, fieldset, legend
  • iframe, embed, object, applet
  • marquee

Anderen Elementen wird »Layout« zugewiesen, sobald Sie (unter anderem) mindestens eine der folgenden Deklarationen für dieses Element vornehmen:

  • position: absolute
  • float: left, float: right
  • display: inline-block
  • width: beliebiger Wert außer auto
  • height: beliebiger Wert außer auto

Mit der Einführung des Internet Explorers 7 kamen weitere Deklarationen hinzu:

  • overflow: hidden, overflow: scroll, overflow: auto
  • overflow-x: hidden, overflow-x: scroll, overflow-x: auto
  • overflow-y: hidden, overflow-y: scroll, overflow-y: auto
  • position: fixed
  • min-width: beliebiger Wert
  • max-width: beliebiger Wert
  • min-height: beliebiger Wert
  • max-height: beliebiger Wert

Für Inline-Elemente gilt: width und height lösen »Layout« lediglich im Quirks Mode aus.

Es gibt keine Möglichkeit, »Layout« für ein Element explizit zu entfernen. Stattdessen müssen Sie die entsprechenden Eigenschaften auf ihren Initialwert zurücksetzen. Im Allgemeinen ist »Layout« jedoch erwünscht, oder anders formuliert: Viele IE-Bugs können Sie beheben, indem Sie bei einem Element »Layout« verursachen. Ihre Aufgabe ist es, den Weg zu finden, der im konkreten Fall die wenigsten »Nebenwirkungen« verursacht. Im weiteren Verlauf dieses Buchs werden Sie einige Beispiele finden.

Zum Seitenanfang

CSS-Hacks für den Internet Explorer

Wie bereits erwähnt, sind es nicht die Browser, die CSS überhaupt nicht verstehen, mit denen Webautoren täglich zu kämpfen haben, sondern die Browser, die CSS fehlerhaft interpretieren: Von unlesbaren Texten und unzugänglichen Inhalten über inaktive Links bis hin zum Browserabsturz kann in solchen Fällen alles passieren. Die Vielzahl an Browsern und deren zum Teil eklatant unterschiedliche CSS-Implementierungen verbieten es, ein einfaches Stylesheet ungetestet anzubieten in der Hoffnung, die Webseite sehe schon auf allen Browsern so aus wie auf dem Entwicklungsbrowser. Deshalb müssen Webautoren ihre Stylesheets entschärfen und dürfen jedem Browser nur das zumuten, was er entweder richtig oder gar nicht interpretiert. Um dies zu bewerkstelligen, setzen Webautoren sogenannte CSS-Hacks ein, also Regeln bestimmter Syntax, die entweder nur spezielle Browser bedienen oder CSS vor diesen verbergen.

CSS-Hacks sind oft nicht besonders intuitiv; sie verlangen nach gut dokumentierenden Kommentaren, regelmäßiger Kontrolle in den aktuellen Browserversionen und einem vertrauten Umgang mit der Syntax von CSS. Darüber hinaus lässt sich nahezu jeder Filter mit einem anderen kombinieren. Das »Austricksen« unterschiedlicher Browser ist manchen eine Qual, anderen eine allzu große Verführung.

Webautoren müssen bei jedem Projekt erneut die Balance finden zwischen aufgeräumtem Code und einer möglichst breiten Kompatibilität – keine leichte Aufgabe, sogar für Profis ... Es empfiehlt sich ein regelmäßiger Blick auf die Seite der CSS-Hacks, um halbwegs auf dem aktuellen Stand zu bleiben. Die Seite wird gut gepflegt und ist immer ein ergiebiger Ausgangspunkt für gegenwärtige und zukünftige Recherchen.

Die große Anzahl aller bekannten CSS-Hacks macht es leider unmöglich, sie alle im Rahmen dieser Einführung zu behandeln. Exemplarisch folgen an dieser Stelle einige Filter für den Internet Explorer, den Browser, mit dessen unterschiedlichen Problemen in seinen verschiedenen Varianten Webautoren am häufigsten zu kämpfen haben.

CSS-Hacks für den Internet Explorer

IE 6

Der IE 6 interpretiert den Selektor * html als einfaches html. Dies nennt man den »Star-HTML-Hack«. Ein Element strong unterhalb eines Elements html unterhalb eines beliebigen Elements kann es nicht geben, da das html-Element keine Vorfahrenelemente besitzt. Vernünftige Browser verstehen Regeln daher nicht, die durch diesen Selektor eingeleitet werden – der IE ignoriert den Stern und wendet die Regel an. Listing 6.5 zeigt die Anwendung des Hacks.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Browsertest</title>
    
    <style type="text/css">
      /* <![CDATA[ */
      * html strong {
        display: none;
      }
      /* ]]> */
    </style>
  </head>
  
  <body>
    <p>Sie verwenden <strong>nicht</strong> den Internet Explorer ab Version 5.</p>
  </body>
</html>
Listing 6.5: Die Anwendung des Star-HTML-Hacks

IE 7

Eine Variante des Star-HTML-Hacks betrifft den IE ab Version 7. Da das Element html das Stammelement eines Webdokuments ist, kann es auch keine Geschwisterelemente haben. Dennoch verstehen IE 7 und IE 8 den eigentlich unsinnigen Selektor * + html; in diesen Browsern selektiert der Universalselektor auch Kommentare und Dokumenttyp-Deklarationen, die er als Geschwisterelemente des Elements html ansieht.

* + html strong {
  display: none;
}

Leider interpretiert auch Opera ab Version 7.5 diesen Selektor, allerdings nur bei gleichzeitiger Verwendung einer XML-Deklaration. Die Alternative *:first-child + html zeigt dieses Verhalten nicht und spricht ausschließlich den IE an.

*:first-child + html strong {
  display: none;
}

IE 8

Um CSS lediglich an den IE 8 auszuliefern, können Sie sich einen Kommentarfehler zunutze machen. Folgende Regel ist eigentlich auskommentiert; der Kommentar wird erst nach dem Deklarationsblock ordnungsgemäß geschlossen. IE 8 interpretiert die Regel trotzdem:

/*/ strong {
  display: none;
} /* */

Zum Zeitpunkt der Drucklegung dieses Buchs war der IE 8 nur als Betaversion verfügbar. Möglicherweise haben die Entwickler den Fehler in der Zwischenzeit behoben. Werfen Sie in diesem Fall einen Blick auf die Seite http://css-discuss.incutio.com/?page=IE8 und schauen Sie, ob mittlerweile ein neuer CSS-Hack bekannt ist.

Zum Seitenanfang

Progressive Enhancement

Im Englischen hat sich der Begriff Progressive Enhancement für CSS-Anwendungen eingebürgert, die alte Browser zwar nicht verstehen, neuere aber zum Nutzen des Lesers umsetzen. Diese Aufwertung, und damit das Einsetzen der neuen Features, verfolgt zwei Ziele:

  • Die Ergonomie von Websites soll verbessert werden, und sei es nur für die 20 oder 30 Prozent der Nutzer, deren Browser das CSS in vollem Umfang verstehen.
  • Sowohl die Browserhersteller als auch die Autoren der W3C-Empfehlungen sind darauf angewiesen, dass CSS in der Praxis eingesetzt wird, um Rückmeldungen von Nutzern und Webautoren zu erhalten, damit sie sinnvoll an CSS und dessen Implementierung weiterarbeiten können.

Darüber hinaus bietet modernes CSS so viele faszinierende Möglichkeiten, dass es einfach Freude bereitet, sie einzusetzen und mit den zahlreichen Funktionen zu spielen.