CSS 2.1 ::Artikel

Internet Explorer 7 — Hacks und Neuerungen

Vorbemerkung:
Auch wenn der Nachfolger des Internet Explorer 7, der IE 8, bereits Wellen schlägt, bleibt diese Seite den Verbesserungen am IE 7 vorbehalten. Die Neuerungen am IE 8 werden zu gegebener Zeit in einem anderen Artikel behandelt.

Diese Seite beantwortet momentan im Wesentlichen drei Fragen:

Nachdem die Arbeiten an der Rendering- Engine des Internet Explorer 7 am 23. März 2006 offiziell abgeschlossen wurden, ist am 18. Oktober 2006 auch die Finalversion erschienen.

Das bedeutet für Webschaffende, dass die Anzahl der IE-7-Nutzer täglich wächst (insbesondere mit dem automatischen Update auf die neue Browser- Version nach dem 01. November 2006) und wir unsere Layouts auch auf IE 7 abstellen müssen. Änderungen an der Rendering- Engine sind erst im Rahmen einer neuen Version wieder zu erwarten. Deshalb muss man davon ausgehen, dass die Probleme, die nun noch vorhanden sind, in dieser Version nicht mehr beseitigt werden.

In der Tat fehlt es beim IE noch an vielen Ecken und Enden: die Werte transparent und inherit an allen Eigenschaften, die Tabelleneigenschaften insgesamt oder die Pseudoklassen :focus und :lang sind nur einige Beispiele.

Anders als bisher müssen Webschaffende heute aber nicht wieder Jahre auf Bugfixes warten, denn die gute Nachricht ist, dass Microsoft für die Zukunft häufigere Updates nach dem Vorbild des Firefox plant. Es soll eine Fehlerdatenbank angelegt werden, die in etwa wie Bugzilla verwaltet wird und auch öffentlich für IE-7-Feedback zugänglich ist (dies allerdings nur, wenn die Feedback-Site nicht 'temporär geschlossen' ist). Eine Erläuterung dazu findet sich im IE-7-Blog.

Weiter bietet das IE-Team noch Hilfen und Werkzeuge, die es Webdesignern leichter machen sollen, ihre Websites für IE 7 zu aktualisieren:

Ein hilfreiches, aber einfaches Tool ist der IP netrenderer. Dort lassen sich Screenshots von beliebigen Webdokumenten erstellen, die auch unmittelbar ausgegeben werden. Sie zeigen die Darstellung der Webseite, wie sie im IE 5.5, im IE 6 und im IE 7 aussieht. Besonders aufschlussreich ist die Ausgabe der Differenzen zwischen IE-6- und IE-7-Rendering oder die überlagerte Darstellung. Dadurch fallen Unterschiede sofort ins Auge.

Was ist zu tun?

  1. Wer sich bisher noch nicht in die Aspekte, Probleme, Hacks und Filter des Layout mit dem IE 7 eingearbeitet hat, sollte damit jetzt beginnen. Weiter unten auf dieser Seite werden einige Workarounds für die Probleme vorgestellt, die jetzt immer noch vorhanden sind. Ein anderer Anlaufpunkt könnten die Browser- Support- Tabellen auf TheStyleworks.de sein.

    Viele Fehler und Eigenheiten des IE/Win 6 wurden bis heute zur Entwicklung spezieller Hacks genutzt. Mit Hilfe dieser Hacks lassen sich innerhalb von Stylesheets besondere Regeln speziell für IE/Win 6 einführen. Praktisch alle diese Browser-Bugs wurden im neuen IE 7 beseitigt, zum Teil jedoch nur im Quirks- Modus, zum Teil ebenfalls im Strict- Modus.

    Wer also sein Layout auf einem Dokumententyp im Strict-Modus basiert und gleichzeitig mit den bekannten Hacks arbeitet, kann damit im IE 7 Schiffbruch erleiden. Dasselbe gilt für alle Webseiten, die bereits online sind: unter bestimmten Umständen und abhängig vom Kontext können Layouts bei Verwendung des IE 7 fehlerhaft sein, auch wenn sie bis heute mit dem IE/Win 6 problemlos funktionieren.

    Viele Hacks bestehen nur aus einigen zusätzlichen Deklarationen, die für die Korrektur eines Fehlers im IE 6 sorgen, aber sonst keine Auswirkungen haben. Andere CSS-Hacks bestehen aus zwei Teilen: einer Regel oder Deklaration, die dazu gedacht ist, einen bestimmten Fehler des Browsers auszugleichen, und einem Filter, mit dem diese Regel vor allen anderen Browsern verborgen wird. Mehr über CSS-Hacks, insbesondere über Hacks am Box-Modell, findet man auf der Seite Box-Modell-Hacks.

    Wenn im IE 7 beide Teile eines Hacks korrigiert sind, ist alles in Ordnung, denn dann verhält IE 7 sich so wie alle anderen modernen Browser auch. Das gleiche gilt, wenn beide nicht korrigiert wurden, denn dann bleibt alles beim alten. Problematisch wird es, wenn nur einer der beiden verwendeten Browserfehler korrigiert wurde. Man kann das leicht an diesem Beispiel nachvollziehen:

    div#1 p { float: right; margin-right: 50px; } div#1 > p { float: right; margin-right: 100px; }

    Dieser Hack soll die verdoppelten Breiten der Außenabstände an floatierten Boxes im IE 6 (engl. 'double margin float bug') korrigieren und nutzt dazu den Umstand aus, dass IE 6 den Kindselektor nicht erkennt. Der Außenabstand einer floatierten Box wird zuerst mit 50 Pixel Breite deklariert und anschließend für standardstreue (Nicht-IE) Browser auf 100 Pixel verdoppelt. Die Breite von 100 Pixeln wird vom IE/Win 6 nicht wahrgenommen.

    Es gibt also hier 4 mögliche Fälle, von denen zwei harmlos sind. Tatsächlich ist es so, dass im IE 7 beide Browserfehler behoben sind und daher in Bezug auf dieses Beispiel kein Problem mehr besteht.

    Ähnlich sieht es im folgenden Fall aus, einem Auszug aus dem Stylesheet dieser Website:

    html > body { /* Gilt nicht für IE */ max-width: 1005px; min-width: 820px; } * html body { /* Gilt nur für IE */ width: 1005px; }

    Hier liegt das Problem so:

    1. Der >-Selektor wird durch den IE 7 erkannt, sodass die Browserweiche die neueste Version des IE nicht mehr ausfiltert.
    2. Die Eigenschaften min-width und max-width erkennt der IE 7 ebenfalls.
    3. Der *-html-Selektor wird von IE 7 jetzt übergangen, da die Seite im Strict-Modus codiert ist.

    Das bedeutet, dass der IE 7 sich in diesem Fall genauso wie die anderen standardstreuen Browser auch verhält. Besondere Hacks für IE 7 sind nicht notwendig. Wäre die Seite im Quirks-Modus codiert, würde IE 7 auf eine feste Breite von 1005 Pixel zurück fallen.

  2. Wenn nichts mehr hilft, kann man immer noch auf das Script IE7 von Dean Edwards zurück greifen. Nach dem Erscheinen der Finalversion werden nicht sofort alle Nutzer des IE 6 auf IE 7 umsteigen. Für einen gewissen Zeitraum müssen wir also beide Versionen bedienen. Mit dem Script korrigieren wir die Fehler des IE/Win seit der Version 5 und ersetzen damit fast alle bekannten Hacks. So können wir standardsgemäßes CSS notieren und zwingen IE 5+ gleichzeitig dazu, sich an Problemstellen zumindest standards-ähnlich zu verhalten.
  3. Microsoft selbst empfiehlt, konditionelle Kommentare anstelle von CSS-Hacks zu verwenden.
  4. Bis heute sind viele Unzulänglichkeiten des Internet Explorer 7 bekannt geworden. Um den Anschluss nicht zu verlieren, sollte man sich, wann immer möglich, auf dem Laufenden halten:

Wie wurden die bekannten Fehler behoben?

Im Folgenden sollen die bekannten Bugs kurz vorgestellt und anschließend darauf eingegangen werden, inwieweit die Bugs und ihre Hacks im IE 7 Risiken und Nebenwirkungen verursachen und inwieweit die zugrunde liegenden Probleme gelöst sind.

Selektoren, Pseudoklassen, Pseudo-Elemente

Auf diesem Gebiet hatte der IE bisher ein deutliches Defizit. Es ist unschwer zu erkennen, dass er hier den Anschluss an die Spitzengruppe wieder gefunden hat.

Unterstützung aller Selektoren bzw Kombinatoren:

Es gibt drei Selektoren, die IE/Win 6 bisher nicht erkannt hat: den Attributselektor, den Nachbarselektor und den Kindselektor. Alle drei werden durch IE 7 unterstützt.

Star-HTML-Selektor-Bug

Der *-HTML-Selektor-Bug ist ein Fehler, der seit der Einführung der Trident-Engine des IE/Win 4 mit dabei ist. Er wurde bis heute weithin genutzt, um Regeln nur für den IE zu filtern. Auf der Seite CSS-Hacks am Box- Modell ist er genauer erklärt.

Im IE 7 ist der *-HTML-Selektor für den Strict-Modus deaktiviert, kann aber bei Verwendung des Quirks-Modus weiter genutzt werden.

Mehrfache Klassenselektoren:

Mit CSS 2 sind auch mehrfache Klassen im selben Selektor erlaubt, wie in diesem Beispiel:

E.val1.val2 { Deklarationen }

IE bis Version 6 war hier noch auf dem Stand von CSS 1, das nur eine Klasse pro Selektor zuließ. In Regeln mit mehrfachen Klassenselektoren akzeptiert IE 6 nur den letzten Selektor. Für den IE 7 ist das Problem jetzt partiell gelöst: es können von Version 7 an mehrere Klassen in demselben Selektor verarbeitet werden — aber nur, wenn man im Strict-Modus arbeitet.

Die Beispielseite für mehrfache Klassenselektoren gibt eine Illustration für das Fehlverhalten des IE/Win bis zur Version 6.

Pseudoklasse :first-child

Die Unterstützung der Pseudoklasse :first-child fehlte dem IE 6 immer noch, wurde aber jetzt auch Realität. Bleibt zu hoffen, das die Implementierung der strukturellen Pseudoklassen aus CSS 3, wie :last-child, :first-of-type usw., nicht auch so lange auf sich warten lässt.

Pseudo-Elemente

Die Spezifikation schreibt für Pseudo-Elemente vor, dass sie nur am Ende aller Selektoren notiert werden dürfen, d. h. sie müssen als letztes vor der öffnenden geschweiften Klammer stehen. IE 7 prüft diese Regel jetzt wirklich strikt ab, nicht nur im Strict-Modus, sondern auch im Quirks-Modus. Auf ein Pseudo-Element muss direkt ein Leerzeichen folgen, alles andere wird als Fehler angesehen.
Beispiele (bitte achten Sie auf das Leerzeichen vor der '{' ):

h1 + p:first-line { font-variant: small-caps; } /* Das geht. */

h1 + p:first-line{ font-variant: small-caps; } /* Das geht nicht. */

Dynamische Pseudoklasse :hover für alle Elemente

Wenn auch viele Bugs des IE 6 mehr oder weniger mit der Pseudoklasse :hover zu tun haben, ist dies der einzige, der ausschließlich durch :hover verursacht wird.

Bis zur Version 6 war der Hover-Effekt nur auf Anker, d. h. Elemente a, wirksam. Von der Version 7 an wird die Pseudoklasse :hover, wie in der Spezifikation CSS 2.1 für dynamische Pseudoklassen verlangt, auf alle Elemente angewandt. Dadurch erhält auch das Problem zwischen dynamischen Pseudoklassen und benannten Ankern eine neue Aktualität.

Fazit: Bei den Selektoren verhält IE 7 sich fehlerlos, solange man sich als Webdesigner selbst an die Regeln hält. Im Bereich der Pseudoklassen und Pseudo- Elemente sind die einzigen Verbesserungen bei :hover und :first-child festzustellen. Mehr nicht.

Das Box- Modell

Verschwinden des unteren Außenabstandes beim Überfahren (bottom-margin bug on :hover)

Dieser Bug des IE 6 bewirkt, dass beim Überfahren von Navigationslisten mit der Maus jeweils der untere Außenabstand des vorletzten Links verschwindet und die Menüpunkte dadurch ungewollt zusammenrücken. Der Bug kann auf dieser Beispielseite von Petrioli Gabriel betrachtet werden.

Der Fehler tritt nur auf, wenn die Anker einer Linkliste als Block- Level- Elemente direkt untereinander stehen und außerdem bestimmte andere Bedingungen zutreffen, eine davon ist z. B. die Installation von SP 2 mit Windows XP. Er ist im IE 7 korrigiert, lässt sich anderenfalls aber einfach dadurch vermeiden, dass man jedes Element a einer Navigation in einem Listenelement li unterbringt.

Fazit: Problem im IE 7 beseitigt.

Border-style-Bug

Für Rahmen, die mit 1 Pixel Breite und dem Rahmenmuster dotted deklariert sind, stellt IE 6 den Wert dashed anstelle des Wertes dotted dar. Im IE 7 werden als punktiert deklarierte Rahmen nicht mehr strichliert, sondern tatsächlich punktiert dargestellt.

Fazit: Problem im IE 7 beseitigt.

Border-Chaos Bug

Dieser Fehler ist erst neu mit der Version 6 des IE. Er tritt nur auf, wenn einige bestimme Bedingungen zusammen treffen:

  • Es müssen zwei Block- Boxes direkt untereinander stehen.
  • Die zweite Box hat einen negativen oberen Außenabstand, dessen Größe keine Rolle spielt.
  • Für die zweite Box oder eine ihrer Nachfahren ist mindestens ein Rahmen deklariert.

In dem Fall werden die Inhalte der Boxes zwar korrekt positioniert, die Darstellung von Rahmen und Hintergrund bricht jedoch völlig zusammen. An einem Beispiel zum Border-Chaos ist dieser Effekt gut erkennbar.

Man umgeht diesen Bug am besten, indem man alle beteiligten Boxes relativ positioniert. Das korrigiert ihn in IE 6, hat aber keine sonstigen Auswirkungen auf IE 7.

Leider muss man feststellen, dass dieses Problem nicht vollständig gelöst wurde. Auch in der Version 7 ist IE noch auf die relative Positionierung angewiesen.

Fazit: IE 7 hat hier noch Mängel, ist aber jetzt nicht mehr ungenügend.

Positionierung mit float

IE/Win 6 hat insbesondere auf dem Gebiet von float und clear einige Probleme:

Doppelter Außenabstand bei float (Double Float Margin Bug)

Dieser Bug tritt immer dann auf, wenn eine Block- Box innerhalb einer anderen Block- Box floatiert ist und gleichzeitig einen Außenabstand in derselben Richtung hat, d. h. wenn die Floatierung nach links geht und auch margin-left deklariert ist oder wenn die Floatierung nach rechts geht und auch margin-right deklariert ist. In dem Fall wird die deklarierte margin durch den IE verdoppelt.

Falls mehrere Floats hintereinander stehen, tritt der Fehler nur beim ersten Float auf. Das ist auch im Beispiel zum Double-Float-Margin-Bug gut erkennbar.

Der Hack für diesen Fehler ist einfach: wir ergänzen die Regel für den Float um die Deklaration display:inline.

Nach dem Standard CSS 2.1 werden Elemente automatisch zu Block- Level- Elementen, wenn wir sie mit float positionieren. Die Deklaration von display muss in diesem Fall ignoriert werden. Das funktioniert auch in allen modernen Browsern korrekt (einschließlich IE 7), lediglich im IE 6 gibt es die kleine Nebenwirkung auf den Float.

Fazit: Problem im IE 7 beseitigt.

Duplizierter Außenabstand (Duplicate Indent)

In einer ähnlichen Konstellation wie oben beschrieben kann sich auch der Fehler des Duplizierten Außenabstands bemerkbar machen. Dieser äußert sich so, dass die für eine floatierte Box deklarierte margin sich als Einzug der ersten Zeile des daneben stehenden Fließtexts wiederholt. Damit das passiert, müssen folgende Bedingungen erfüllt sein:

  • Die floatierte Box muss im Quelltext direkt vor dem Fließtext stehen, der auf dem Bildschirm neben dem Float dargestellt werden soll.
  • Der Fließtext muss aus anonymen Inline- Boxes bestehen, d. h. nicht von Tags eines Elementes wie p, div oder anderen eingefasst sein. Das trifft z. B. zu, wenn der Float im Quelltext innerhalb eines Absatzes, aber nicht davor, auftritt.
  • An die Stelle der anonymen Inline- Boxes können auch Inline- Level- Elemente wie img treten.

Eine umfassende Erläuterung dieses Fehlers hat Steve Clason zusammen gestellt. Die Lösung ist überraschend einfach und dieselbe wie oben: wir deklarieren display:inline für das floatierte Element. Das löst das bestehende Problem und birgt auch keine neuen Probleme mit dem IE 7.

Fazit: Problem im IE 7 beseitigt.

Peekaboo-Bug

Dieser Browserfehler tritt bei folgender Konstellation auf:

  1. Eine floatierte Box, deren umschließende Box nicht floatiert ist.
  2. Auf den Float folgen innerhalb der umschließenden Box noch weitere Inhalte.
  3. Ebenfalls innerhalb der umschließenden Box vorhanden sein muss ein Block- Level- Element, dass mit der Eigenschaft clear deklariert ist, auf den Float folgt und ihn in der Darstellung direkt berührt.

Der Peekaboo-Bug bewirkt, dass Text neben der floatierten Box unter bestimmten Umständen mehr oder weniger verschwindet und wieder auftaucht. Ausgelöst wird dieses Verhalten unter anderem, indem man mit der Maus über Links im Text neben dem Float fährt. Auf der Beispielseite zum Peekaboo-Bug von John Gallant ist der Fehler ausführlich erklärt.

Auch hier ist die Korrektur relativ einfach: wir deklarieren position:relative für zwei Boxes:

  1. Die umfassende Box, die die floatierte Box sowie den Text neben der floatierten Box und die mit clear deklarierte Box umfasst.
  2. Die floatierte Box selbst.

Das berichtigt die Darstellung in IE 6 und hat für standardstreue Browser keine Auswirkung. Der Bugfix hat im IE 7 ebenfalls keine negativen Folgen.

Fazit: Problem im IE 7 beseitigt.

Guillotine-Bug

Dieser Bug ist dem oben beschriebenen Peekaboo-Bug ähnlich, mit einigen kleinen Unterschieden:

  • Die floatierte Block- Box wird nicht von einer anderen Box gefolgt, die mit der Eigenschaft clear deklariert ist. Dadurch kann der Float nach unten über den umschließenden Block hinaus stehen.
  • Die auf den Float folgenden Inhalte dürfen nicht floatiert sein.
  • Die neben dem Float dargestellten Inhalte enthalten auch Links, die mit a:hover gestaltet sind.

Die bekannteste genauere Erläuterung dieses Bugs finden wir auf der Beispielseite zum Guillotine-Bug von John Gallant.

Die Auswirkung des Guillotine-Bugs besteht nun darin, dass

  1. der umschließende Block bis zum unteren Ende des Floats aufgezogen wird.
  2. der umschließende Block beim Überfahren einiger Links in seiner korrekten Höhe gezeigt und gleichzeitig der überstehende Teil des Floats abgehackt — guillotiniert — wird.

Auf seiner Seite beschreibt John Gallant einige Korrektur-Hacks, die aber fast alle im IE 7 keine Probleme verursachen. Aufpassen muss man nur, wenn man zur Korrektur die Pseudoklasse :after verwendet, die auch ein IE 7 noch nicht erkennt.

Fazit: Problem im IE 7 beseitigt.

Verschwindender Listenhintergrund (Disappearing List Background Bug)

Die Bezeichnung sagt schon, was es mit diesem Browserfehler auf sich hat: Hintergrundfarben und Hintergrundgrafiken an Listen werden nicht dargestellt oder verschwinden. Auch dieser Bug tritt nicht immer auf, sondern nur, wenn die Liste sich in einem floatierten Container befindet. Matt Smith hat den Disappearing List Background Bug dokumentiert.

Die Lösung ist ähnlich der Lösung des Peekaboo-Bugs und absolut IE-7-verträglich: wir deklarieren position:relative für den floatierten Block.

Fazit: Problem im IE 7 beseitigt.

Verdoppelte Zeichen (Duplicate Character Bug)

Der Duplicate-Character-Bug wirkt sich so aus, dass eine Anzahl Zeichen aus einem floatierten Element doppelt auf dem Bildschirm ausgegeben wird. Folgende Bedingungen sind dazu notwendig:

  • Innerhalb eines floatierten Containers befinden sich zwei oder mehr weitere Container, die aufeinander folgen und dabai ebenfalls floatiert sind.
  • Die inneren Floats liegen direkt am äußeren Float an oder sind an der rechten Seite nicht mehr wie 3 Pixel von seiner Außenkante entfernt.
  • Für rechts-floatierte Boxes müssen sich die 3 Pixel Maximalabstand auf der linken Seite befinden.
  • Zwischen den inneren Floats sind Elemente im Quelltext eingeschlossen, die nicht auf dem Bildschirm dargestellt werden, z. B. Kommentare oder mit display:none deklarierte Elemente.

Hinter dem letzten innenliegenden Float werden nun Zeichen seines Inhalts ein zweites Mal ausgegeben. Es beginnt mit dem Ende des Inhalts und die Anzahl der Zeichen ist abhängig von der Anzahl der zwischen den Floats eingeschlossenen, nicht dargestellten Elemente. Für jedes dieser Elemente werden zwei Zeichen wiederholt. Alle, die an einer längeren Behandlung des Duplicate-Character-Bug interessiert sind, seien hier ebenfalls auf die Website von John Gallant verwiesen.

Zur Abhilfe gibt es mehrere Möglichkeiten:

  • Man deklariert margin-right:-3px, wenn der letzte innen liegende Float nach links ausgerichtet ist, bzw. margin-left:-3px, wenn dieser Float nach rechts ausgerichtet ist.
  • Alternativ deklariert man die Breite der Floats mit einem Unterschied von mehr als 3 Pixel.
  • Wenn möglich, kann man auch Kommentare und anderes zwischen den Floats ganz entfernen bzw. weglassen.
  • Falls keine der genannten Möglichkeiten nutzbar ist, können wir den Kommentar oder nicht dargestellten Text auch im Microsoft's Konditionelle Kommentare einfassen. Wir müssen sie aber mit einem NOT-Zeichen vor dem 'IE' versehen:

    <!--[if !IE]>... Kommentare ...<![endif]-->

Alle genanten Möglichkeiten sind ohne Gefahren für den IE 7 einsetzbar.

Fazit: Problem im IE 7 beseitigt.

3-Pixel-Textsprung (3 Pixel Text Jog)

Dieser entsteht immer, wenn normaler Fließtext neben einem floatierten Block steht. Ist der Float nach links ausgerichtet, zeigt sich eine 3 Pixel breite Lücke auf der linken Seite des Textes, der rechts daneben steht. Diese Lücke endet mit einem Sprung, wenn das untere Ende des Float erreicht ist. Der Text muss dazu nicht an den Float andocken, sondern einfach nur auf gleicher Höhe daneben stehen. Bei einem nach rechts orientierten Float sind die Auswirkungen analog seitenverkehrt.

Der Grund für diesen Fehler ist, dass IE 6 offenbar den Line- Boxes auf gleicher Höhe mit dem Float einen Abstand von 3 Pixeln mitgibt. Die genaue Erläuterung des 3-Pixel-Textsprung ist auf Positioniseverything.net veröffentlicht.

Abhilfe schafft eine sehr kleine Höhenangabe, die wir durch den *-HTML-Selektor speziell für den IE 6 herausfiltern:

* html p { height: 1%; margin-left: 0; }

Das Problem selbst tritt im IE 7 nicht mehr auf, für IE/Win 6 ist dieser Trick nur noch eingeschränkt verwendbar, denn bei Verwendung des Quirks-Modus funktioniert der *-HTML-Selektor auch im IE 7 noch.

Fazit: Problem im IE 7 beseitigt.

Absolute Positionierung

Positionierung und Hintergründe mit fixed

Es ist allgemein bekannt, dass IE/Win den Wert fixed dort, wo er auftaucht, nicht korrekt verarbeiten kann: weder mit der Eigenschaft position noch mit der Eigenschaft background-attachment.

Zur Bereinigung dieses Fehlers wurden eine Reihe von Hacks entwickelt, die auf Bugs, proprietären Eigenschaften oder konditionellen Kommentaren basierten.

In dem Artikel position: fixed für IE/Win 6 wurde seinerzeit ein Script vorgestellt, mit dem dieses Manko des IE/Win problemlos behebbar ist.

Mit dem Advent des IE 7 ist all das nicht mehr notwendig — er verarbeitet den Wert fixed so wie jeder andere standardstreue Browser auch. Er wird allerdings nicht alle Tricks und Hacks problemlos schlucken, die erdacht wurden, um den Wert fixed mit den Versionen 5 und 6 funktionsfähig zu machen. Lediglich die konditionellen Kommentare und das von Andrew Clover erstellte Script werden hier problemfrei Bestand haben können.

Fazit: Problem im IE 7 beseitigt.

Fehlender Scrollbalken (Unscrollable Content Bug)

Dieser Browserfehler wirkt sich nur aus, wenn wir mit Absoluter Positionierung arbeiten. Es kommt relativ häufig vor, dass man eine absolut positionierte Box als Kindelement einer relativ positionierten Box platziert. Wenn die Höhe der absolut positionierten Box dann größer als die Höhe des Browserfensters ist, erscheint im Normalfall der seitliche Scrollbalken.

Beim IE bis Version 6 werden durch den Scrollbalken jedoch nur die Inhalte sichtbar, die der Höhe des Bildschirms entsprechen. Im Vollbildmodus erscheint gar kein Scrollbalken mehr. Die tiefer liegenden Inhalte bleiben unzugänglich. Eine ausführliche Beschreibung des Unscrollable-Content-Bug findet sich einmal mehr bei John Gallant.

Für Version 6 und eher des IE lässt sich dieser Browser-Bug ganz einfach korrigierwn, indem man height:1% für die relativ positionierte Box deklariert. Dann läuft alles fehlerlos, ebenso wie im IE 7.

Fazit: Problem im IE 7 beseitigt.

Fehler bei width:auto

Dieser Browserfehler tritt nur bei Verwendung der absoluten Positionierung auf.

Wenn man ein Element absolut positioniert, wird seine horizontale Lage eindeutig festgelegt, indem man zwei der drei Eigenschaften left, right und width definiert. Die dritte wird dann laut Spezifikation automatisch ermittelt, erhält also den Wert auto.

Bei Festlegung der Eigenschaften left und width oder bei Angabe von right und width gibt es keine Probleme.

Ebenso eindeutig ist es, wenn man nur left und right deklariert und die Breite des Elements automatisch daran angepasst wird. Ganz nebenbei ist dies eine Technik, die einige interessante Gestaltungsmöglichkeiten eröffnet. Sie funktioniert auch einwandfrei mit allen Browsern.

Fast allen. Nur der Internet Explorer 6 widersteht beharrlich allen Versuchen, diese Technik anzuwenden und besteht auf einer Lösung per JavaScript.

Doch das hat mit der Version 7 ein Ende. Es wird nicht nur kein JavaScript mehr benötigt, sondern man kommt hier auch ohne alle Hacks aus. Sappradi!

Fazit: Problem im IE 7 beseitigt.

Unvorhersehbare Prozentangaben (Quirky Percentages Bug)

Ein bekanntes Problem des IE 6 ist es, dass Blöcke, die mit Prozentangaben formatiert sind, oft an einen anderen Platz springen, wenn man sie mit der Maus überfährt. Ganz kurz erklärt, ist der Grund dafür folgender:

Nach der Spezifikation sollen Prozentangaben in der Höhe und in der Breite sich auf die Dimension des umschließenden Blocks beziehen, wenn sie für Positionierungen oder für Eigenschaften des Box- Modells verwendet werden. Dort wird auch vorgegeben, dass das Ergebnis undefiniert ist, wenn die Dimension des umschließenden Blocks von der Dimension des aktuellen Elements abhängt.

IE 6 bezieht Prozentangaben jedoch beim ersten Aufbau der Seite auf das Element body. Überfährt man dann die Seite mit dem Cursor, 'erkennt' er seinen Fehler und stellt diese Blocks an die Stelle, die er mit Hilfe der momentanen Dimensionen des Layouts errechnet, was natürlich ebenfalls falsch ist. Auch für diesen Bug findet man eine ausführliche Beschreibung der möglichen Auswirkungen bei Positioniseverything.net.

Es gibt keinen Hack, der dieses Problem völlig löst. Es sind aber drei mögliche Lösungen denkbar:

  • Die beste Lösung ist, Prozentangaben zur Positionierung ganz zu vermeiden.
  • Alternativ verwendet man sie nur abhängig vom Element body.
  • Oder man findet durch Probieren eine Prozentangabe, bei der das Layout in allen Browsern annehmbar aussieht.

Wer einen Hack für diesen Bug verwendet hat, sollte sein Layout prüfen, ob es im IE 7 noch stimmt. Die anderen Lösungen stellen keine Gefahr dar.

Fazit: Auch wenn einige Unschönheiten bleiben, das Problem ist im IE 7 beseitigt.

Textformatierung

Davonschleichender Text (Magik Creeping Text Bug)

Der Name deutet schon an, wie dieser Browserfehler sich bemerkbar macht: Text innnerhalb einer Block- Box 'schleicht' sich Zeile für Zeile weiter über den Rand der Box hinaus. Das passiert aber nicht einfach so, sondern unter bestimmten Bedingungen:

Der Text wird dann um die Breite des Rahmens aus der Box heraus gezogen. Folgen mehrere dieser verschachtelten Boxes aufeinander, läuft der Text in jeder Box weiter hinaus. Mehr Informationen zum Magik Creeping Text Bug hat John Gallant zusammen gestellt.

Korrigieren lässt sich dieser Bug auf drei verschiedenen Wegen:

  • Deklaration eines unteren Rahmens jeweils an der äußeren der beiden verschachtelten Boxes.
  • Die zweite Möglichkeit, ebenfalls an der äußeren Box anzubringen, ist wieder die Deklaration einer minimalen Höhe wie width:1% in Verbindung mit dem *-HTML-Selektor als Filter.
  • Als dritte Möglichkeit bietet sich noch an, diese Kombination generell zu meiden.

Auch hier haben wir bei Verwendung des *-HTML-Selektors das bereits bekannte Problem, dass er im EI 7 nur noch im Quirks-Modus verwendbar ist.

Fazit: Problem im IE 7 beseitigt, kein Text macht sich mehr davon.

Zeilenhöhe-Fehler (Line Height Bug)

Wenn innerhalb eines Fließtextes grafische Zeichen, z. B. dieses: , eingefügt werden, bedingt das im IE 6 eine verringerte Zeilenhöhe. Auf der Beispielseite zum Zeilenhöhe-Fehler ist die verringerte Zeilenhöhe mit dem IE 6 deutlich erkennbar.

Ganz genau genommen wird dieser Bug durch alle replatzierten Inline- Level- Elemente ausgelöst, wie z. B. img, input, textarea, select oder object. Sie bewirken, dass in diesem Fall der Halb-Durchschuss der aktuellen Textzeile mit dem Halb-Durchschuss der Zeilen darüber und darunter zusammenfällt.

Dieser Browser-Bug tritt nur auf, solange die Elemente im normalen Textfluss verbleiben. Sobald man sie durch absolute oder floatierte Positionierung aus dem normalen Fluss herauslöst, wird auch die Zeilenhöhe wieder normal.

Die einzige bekannte Abhilfe hier ist, mit Hilfe des *-HTML-Selektors nur für IE 6 vorsichtig passende Außenabstände oben und unten einzuführen. In den meisten Fällen wird dieser Fehler jedoch nicht korrigiert worden sein, sodass er mit Einführung des IE 7 problemlos entfernt wird.

Fazit: Problem im IE 7 beseitigt.

Welche Hacks gibt es speziell für IE 7?

Wie oben gezeigt, wurden viele der lange bekannten Unzulänglichkeiten des Internet Explorer in der neuesten Version beseitigt. Damit funktionieren auch die Hacks nicht mehr, die auf diesen Fehlern basierten. Gerade dadurch wird aber auch die Problematik der Verwendung von CSS-Hacks deutlich, denn Browserfehler können jederzeit durch den Hersteller berichtigt werden. Sobald der Fehler korrigiert ist, funktioniert auch der Hack nicht mehr und die Seitendarstellung wird falsch.

Wenn es denn unbedingt browserspezifisches CSS sein muss, dann notiert man dieses CSS am besten in ein separates Stylesheet, das nur die abweichenden Regeln enthält. Das Laden eines extra Stylesheets kann man durch serverseitigen Code oder durch konditionelle Kommentare steuern. Man sollte es nach den anderen Stylesheets laden, die darin notierten Regeln ersetzen die entsprechenden Regeln aus den anderen Stylesheets mit Hilfe der Kaskade.

Aber auch denen, die trotz allem auf der Verwendung von CSS-Hacks für IE 7 bestehen, kann inzwischen geholfen werden. Es wurden bereits ein paar einfache Selektor-Hacks für den IE 7 entwickelt. Die sind deshalb möglich, weil einige Selektoren im IE 7 nur bei der normalen regelgerechten Verwendung korrekt funktionieren. Weicht man davon ab, entstehen Fehler, die im Sinne von Hacks ausgenutzt werden können.

Fehlender Selektor

Einer dieser Fehler tritt dann auf, wenn der Einfachselektor auf einer Seite eines Kombinators fehlt. Der Selektor kann rechts oder links vom Kombinator fehlen. Es spielt keine Rolle, ob es sich dabei um den >-Kombinator oder um den +-Kombinator handelt. IE 7 nimmt dann an, dass der fehlende Selektor ein Universal-Selektor ist.

Hack Notierung im Stylesheet Interpretation durch IE 7 Validität
Korrekte Notierung selektor>selektor selektor>selektor
Fehlender Selektor selektor> selektor>* Validiert nicht!
Fehlender Selektor >selektor *>selektor Validiert nicht!
Korrekte Notierung selektor+selektor selektor+selektor
Fehlender Selektor selektor+ selektor+* Validiert nicht!
Fehlender Selektor +selektor *+selektor Validiert nicht!

Fehlender Leerraum

Der '* html'-Hack dürfte inzwischen allen bekannt sein. Dabei wird der Universalselektor für ein ominöses Element oberhalb des Stammelements eingesetzt. Das umgekehrte Konstrukt, bei dem der Universalselektor * auf den Einfachselektor html folgt, ist der Nachfahrenselektor. Laut Spezifikation muss zwischen beiden ein Zwischenraum stehen. Fehlt der Zwischenraum, wird die Anweisung von allen modernen Browsern übergangen. Der Grund dafür ist, dass es ein Element html* nicht gibt.

Anders agiert hier der IE 7: Der interpretiert sich den fehlenden Zwischenraum für den Eigengebrauch einfach dazu. Wenn man also im Stylesheet html* als Selektor notiert anstelle von html *, erhält man eine Regel, die nur der IE 7 erkennt. Das beschränkt sich nicht auf html *, sondern trifft auch zu für body * oder div * oder div a:hover *. Also alle Deklarationen, wo der Stern als Nachfahrenselektor auftritt.

Hack Notierung im Stylesheet Interpretation durch IE 7 Validität
Korrekte Notierung html * html *
Fehlender Leerraum html* html * Validiert nicht!

HTML als Nachbarelement

Da das Element html das Stammelement eines Webdokuments ist, kann es auch keine Nachbarelemente haben. Das bedeutet: eine Regel, in der der Universalselektor über den Nachbarschafts- Kombinator (+) mit dem Selektor html verknüpft ist, trifft auf kein Element des Dokuments zu. So wird das auch durch alle modernen Browser gehandhabt — mit Ausnahme des IE 7. Im Internet Explorer selektiert der Universalselektor auch Kommentare und DOCTYPE-Deklarationen. Diese sieht der Browser als Nachbarn des Elements html. Das spielt aber erst mit der Version 7 eine Rolle, da IE erst jetzt den Nachbarschafts- Kombinator erkennt.

Hack Notierung im Stylesheet Interpretation durch IE 7 Validität
HTML-Nachbar *+html *+html Valides CSS

Summa Summarum

Bisher wurden nur Wege aufgezeigt, mit denen sich Deklarationen speziell für IE 7 isolieren lassen. Oft möchte man aber noch andere Unterschiede machen, z. B. zwischen modernen und alten Browsern, zwischen Internet Explorer und anderen Browsern, usw. Zusätzlich soll alles noch validieren. Die folgende Tabelle gibt eine Übersicht, wie man hier relativ einfach die Spreu vom Weizen trennen kann. Dank geht an David Hammond von Nanobox, der diese Hacks zuerst veröffentlichte.

Hack Wirkt in diesen Browsern Selektiertes Element Validität
* html Nur IE bis Version 6 html Valides CSS
*+html Nur IE, nur Version 7 html Valides CSS
*+html, * html Nur IE, alle Versionen html Valides CSS
html>body Moderne Browser, IE nur Version 7 body Valides CSS
html>/**/body Moderne Browser ohne IE 7 body Valides CSS

Zusammenfassung

In Bezug auf die Browser-Bugs hat Microsoft gute Arbeit geleistet und seine Versprechen zum großen Teil eingelöst. Trotzdem kann das Ergebnis einer genauen Prüfung nicht ganz zufrieden stellen (siehe hierzu auch die Sparte Browser-Support oder die entsprechenden Hinweise in der Referenz). Auch wenn der Internet Explorer damit einen großen Sprung nach vorn gemacht hat, sind ihm Firefox 2.0 und Opera 9, zumindest im Bereich der CSS-Technik, immer noch weit voraus. Dennoch: durch die Einrichtung der IE-Bugbase und die Berücksichtigung der User-Inputs kann man künftig mit häufigeren und qualitativ guten Updates rechnen. Die Gemeinde der IE-Hasser wird es nicht mögen, aber deutliche Schritte in Richtung Webstandards und CSS 3 sind nur mit Microsoft, aber nicht ohne Microsoft, möglich.

Zum Schluss noch einige Links zum Thema:


Home|Vollreferenz|Schnellreferenz|Grundlegendes|Tutorials & Artikel|Quiz|Allgemeines

Die URL dieser Seite ist: www.thestyleworks.de/tut-art/ie7.shtml
Gedruckt am Donnerstag, dem 23. Oktober, 2014.
© Copyright All Contents 2002- 2014 K. Langenberg.
Commercial Use prohibited.


Notizen: