Layout-Probleme mit IE6, IE8 und Opera

[F30]

Hallo zusammen,

ich hab zwei Browser-Bugs auf dieser Seite, bei denen ich nicht so recht auf die Lösung kommen will.
Das betreffende CSS findet sich unter http://www.sg-buechenbach-roth.de/wordpress/wp-content/themes/schachgemeinschaft/style.css

Zunächst mal etwas mit dem IE6, wahrscheinlich ein Bug-Klassiker, aber so lange mache ich noch kein CSS: Der Inhalt wird unter, anstatt neben der Sidebar angezeigt (Bild).
Wahrscheinlich fehlt einfach der Platz, weil die Sidebar wegen des breiten Dropdowns vergrößert wird. Allerdings halfen sämtliche overlow: hidden-Eigenschaften nichts, egal ob auf die Sidebar oder auf die Liste angewendet.
Weiß da vielleicht jemand Rat?

Außerdem noch eine sehr merkwürdige Sache, die mit dem IE8 und mit Opera auftritt: Der margin-left des Inhalts wird nicht vom Eltern-div aus berechnet, sondern von der Sidebar aus. Deswegen entsteht zwischen Sidebar und Inhalt eine große Lücke (Bild).
Mit Google konnte ich so gut wie nichts über diesen Bug finden...

Vielen Dank für eure Hilfe im Voraus!

[ChrisB]

Hi,

Außerdem noch eine sehr merkwürdige Sache, die mit dem IE8 und mit Opera auftritt:

Im FF 2 genauso.

Der margin-left des Inhalts wird nicht vom Eltern-div aus berechnet, sondern von der Sidebar aus.

Das liegt am overflow.

MfG ChrisB

[molily]

Der margin-left des Inhalts wird nicht vom Eltern-div aus berechnet, sondern von der Sidebar aus. Deswegen entsteht zwischen Sidebar und Inhalt eine große Lücke (Bild).

Das ist tatsächlich ein Bug, der darauf beruht, dass die CSS-2.1-Spec das einige Zeit so erlaubte. Beide Spalten verhalten sich als Block Formatting Context, einmal wegen float, einmal wegen overflow:auto. In CSS ist definiert, dass sich die Margin-Box eines BFC mit einem Float überlappen darf. Das heißt, der Margin müsste hinter dem Float verschwinden und von der linken Kante des Elternelements ausgehen, anstatt von der rechten Kante des Floats. (Quelle: Chao/Rudel: Fortgeschrittene CSS-Techniken. S. 259)

Da kannst du im Grunde nur Workarounds verwenden:

• overflow:auto weglassen, sodass der Content-Bereich kein BFC mehr ist, weiterhin margin-left benutzen und das ggf. nötige Einschließen der Floats mit dem klassischen Clearfix bewerkstelligen
• BFC mittels overflow:auto belassen (sodass keine Überlappung der Border-Boxen stattfindet), aber dem dem Float stattdessen ein entsprechend kleines margin-right geben. Oder diesen Abstand über padding-left vom Inhaltsbereich lösen.

Mathias

[Thomas J.S.]

Hallo Mathias,

ich musste jetzt echt schmunzeln. Deine Analyse ist perfekt, aber man muss sich sehr gut mit der Materie auskennen um die Antwort(en) zu verstehen. ("Three-Pixel-Jog", "Negative Backside Margin", "BFC" usw.)
Die Zitate (und/oder Verweise) auf  das Buch finde ich lustig, denn das Buch hat bei der Fülle an Büchern vielleicht 1 von 50 "Webdesigner".

Irgendwie ist das jetzt ein freundliches: YMMD :)

Grüße
Thomas

[molily]

man muss sich sehr gut mit der Materie auskennen um die Antwort(en) zu verstehen.

Man gerät bei einem einfachen CSS-Spaltenlayout leider sehr schnell in Gefilde, wo man ohne dieses Wissen aufgeschmissen ist.

("Three-Pixel-Jog", "Negative Backside Margin", "BFC" usw.)

Was diese Begriffe bedeuten, sollte zumindest teilweise aus  meiner Erklärung und dem Beispieldokument hervorgehen, das die Anwendung demonstriert. Aber ich kann es gerne nachliefern, sofern es daraus nicht klar geworden sein sollte.

• Three-Pixel-Jog ist ein IE-5/6-Bug, der ein Element neben einem Float um 3 Pixel verschiebt, wie man in Beispiel 2 sieht.

• Negative Backside Margin ist ein IE-Fix, bei dem einem Float entgegen seiner Float-Richtung (z.B. float:left > Hinterseite ist right, float:right > Hinterseite ist left) ein negativer margin-right bzw. margin-left gegeben wird. Dieser Fix wird in Beispiel 2 angewendet. (Genauer gesagt funktioniert das Beispiel noch ein wenig anders: Das Element floatet nicht, der negative margin-right hilft trotzdem gegen den Rundungsfehler.)

• Block Formatting Context (BFC) ist ein CSS-internes Element-Verhalten, das von einigen CSS-Eigenschaften angeschaltet wird und das gewisse Auswirkungen hat, die man sich zur Nutze machen kann. Dazu gehören:
   -- Einschließen von Floats
   -- Keine Überlappung mit Floats (BFC liegen automatisch neben Floats)
   -- Sie etablieren einen neuen Float-Kontext, sodass clear sich nicht dokumentweit, sondern nur auf alle Floats im aktuellen BFC auswirkt

• Die Kenntnis von hasLayout habe ich auch stillschweigend vorausgesetzt, sie ist fürs Layouten für IE 6 unverzichtbar. hasLayout ist ein IE-internes Konzept, das auf einer unzureichenden CSS-Umsetzung beruht. IE bis einschließlich 7 kennt kein BFC, aber wenn ein Element »Layout hat« hat, verhält es sich ähnlich wie ein BFC und zeigt noch viele weitere Eigenheiten. Es wird ebenfalls von gewissen CSS-Eigenschaften angeschaltet (z.B. zoom:1). Manche Elemente haben standardmäßig hasLayout. In vielen Fällen muss man Elementen im IE 6/7 hasLayout vergeben, damit das Layout stabil und fehlerfrei ist, um einen BFC zu emulieren oder weil IE das Element ohne hasLayout nicht wie gewünscht darstellen würde.
  Grundlagenartikel zu hasLayout in dt. Übersetzung

Die Zitate (und/oder Verweise) auf  das Buch finde ich lustig, denn das Buch hat bei der Fülle an Büchern vielleicht 1 von 50 "Webdesigner".

Natürlich hat das niemand, aber es gibt im Web keine deutschsprachige Literatur, die diese Sachverhalte so gut darstellt. Ich verweise nur darauf, um meine Quellen offenzulegen, aber auch, um Leuten zu raten, sich so eine Lektüre (am besten diese) anzuschaffen.

Mathias

[MudGuard]

Hi,

ein IE-internes Konzept, das auf einer unzureichenden CSS-Umsetzung beruht.

wieso habe ich da jetzt unzurechnungsfähig gelesen?
Vielleicht hab ich an die IE6-CSS-Umsetzer gedacht ...

cu,
Andreas

[molily]

Zunächst mal etwas mit dem IE6, wahrscheinlich ein Bug-Klassiker, aber so lange mache ich noch kein CSS: Der Inhalt wird unter, anstatt neben der Sidebar angezeigt (Bild).

Hier vermute ich irgendeine Abart des Three-Pixel-Jogs. Du kannst es z.B. dadurch vermeiden, indem du dem IE nicht ganz width:75% gibts (tust du zwar jetzt schon nicht, ist aber immer noch zuviel), oder die Breitenangabe einfach weglässt (Bereich ist automatisch 75% breit).

Mathias

[molily]

Zunächst mal etwas mit dem IE6, wahrscheinlich ein Bug-Klassiker, aber so lange mache ich noch kein CSS: Der Inhalt wird unter, anstatt neben der Sidebar angezeigt (Bild).

Da spielen verschiedene Bugs rein. Einerseits der Three-Pixel-Jog, andererseits Rundungsfehler bei der Umrechnung von Prozentwerten in Pixel.

http://molily.de/temp/css-ie6-float-bugs.html

Chao/Rudel schlagen ein Negative Backside Margin für die rechte Spalte vor (S. 347, 351). Das hilft dagegen, dass die rechte Spalte herunterfällt, aber nicht gegen den weiterhin auftretenden Three-Pixel-Jog (zweites Beispiel).
Der Fix für den Three-Pixel-Jog hilft auch gegen die Rundungsfehler (drittes Beispiel). Im Grunde ist der ja auch nur ein Negative Backside Margin, insofern ist das folgerichtig.
Eine weitere Möglichkeit wäre wie gesagt das floaten der rechten Spalte (viertes Beispiel).
Die ersten vier Beispiele beziehen sich nur auf IE-6-Verhalten. Das fünfte Beispiel ist dann browserübergreifend (Fix für Three-Pixel-Jog für IE 6, BFC mittels overflow:hidden für die rechte Spalte für standardkonforme Browser). Alle Beispiele arbeiten ohne margin-left für die rechte Spalte, weil sie durch hasLayout bzw. BFC automatisch neben dem Float positioniert werden und keine Überlappung stattfindet.

Der Verzicht auf eine feste width für die rechte Spalte hilft ebenfalls gegen die Rundungsfehler. Dann müsste die rechte Spalte mit zoom:1 hasLayout bekommen, weil width als hasLayout-Trigger ausfällt. Der Three-Pixel-Jog tritt dann dennoch auf, insofern reicht es wohl, mit dessen Fix beide Bugs zu umgehen (sehe dritten Beispiel bzw. das browserübergreifende).

Mathias

[F30]

ich musste jetzt echt schmunzeln. Deine Analyse ist perfekt, aber man muss sich sehr gut mit der Materie auskennen um die Antwort(en) zu verstehen. ("Three-Pixel-Jog", "Negative Backside Margin", "BFC" usw.)
Die Zitate (und/oder Verweise) auf  das Buch finde ich lustig, denn das Buch hat bei der Fülle an Büchern vielleicht 1 von 50 "Webdesigner".

Na ja, mit dem "Three-Pixel-Bug" (ich nehme an, das ist das gleiche wie der "-Jog") hatte ich mich schon mal beschäftigt und mit dem "BFC" auch. Solchen Begriffen kann man ja auch gut "hinterhergoogeln", trotzdem bin ich für die weiteren Erklärungen sehr dankbar, denn in dieser Fülle überforderte mich die erste Antwort schone erstmal.

Ich dachte eigentlich, ich hätte den Three-Pixel-Bug bereits mit

  
* html #contentFrame {  
    height: 1%;  
}  

beseitigt. Ist das nicht so?

Der Verzicht auf eine feste width für die rechte Spalte hilft ebenfalls gegen die Rundungsfehler.

Hab ich schon probiert, aber dann machen aktuelle Browser plötzlich komische Sachen.

• Block Formatting Context (BFC) ist ein CSS-internes Element-Verhalten, das von einigen CSS-Eigenschaften angeschaltet wird und das gewisse Auswirkungen hat, die man sich zur Nutze machen kann. Dazu gehören:
  -- Einschließen von Floats
  -- Keine Überlappung mit Floats (BFC liegen automatisch neben Floats)
  -- Sie etablieren einen neuen Float-Kontext, sodass clear sich nicht dokumentweit, sondern nur auf alle Floats im aktuellen BFC auswirkt

Genau, und für letzteres brauche ich es.
Allerdings könnte ich ja, wenn der zweite Punkt für alle Browser stimmt, den margin-left des Inhalts-divs entfernen, oder? Ist das der oben beschriebene Fix für das IE8/Opera-Problem?

[molily]

Ich dachte eigentlich, ich hätte den Three-Pixel-Bug bereits mit

• html #contentFrame {
      height: 1%;
  }

> beseitigt. Ist das nicht so?  
  
Nein, wie du im Beispiel 2 siehst.  
Der Content-Div hat bereits hasLayout dadurch, dass er eine feste width hat, aber die 3-Pixel-Verschiebung ist trotzdem zu sehen. height: 1% ist nichts anderes als ein weiterer Trigger für hasLayout, der aber nichts ändert, wenn das Element eh schon hasLayout hat.  
  

> > Der Verzicht auf eine feste width für die rechte Spalte hilft ebenfalls gegen die Rundungsfehler.  
> Hab ich schon probiert, aber dann machen aktuelle Browser plötzlich [komische Sachen](http://browsershots.org/screenshots/4833a38a956a2d40d3bd70db2031f3d7/).  
  
Das ist ein Safari-Bug, der ebenfalls durch margin + BFC ausgelöst wird:  
</archiv/2009/3/t184458/#m1223359>  
  

> Allerdings könnte ich ja, wenn der zweite Punkt für alle Browser stimmt, den margin-left des Inhalts-divs entfernen, oder?  
  
Ja, das schlägt mein Beispiel auch vor.  
  

> Ist das der oben beschriebene Fix für das IE8/Opera-Problem?  
  
Ja, und für das Safari-Problem.  
  
Mathias

-- 
[JavaScript-Erweiterung für das SELFHTML-Forum](http://forum.de.selfhtml.org/js/doku/)

[F30]

»» Allerdings könnte ich ja, wenn der zweite Punkt für alle Browser stimmt, den margin-left des Inhalts-divs entfernen, oder?

Ja, das schlägt mein Beispiel auch vor.

»» Ist das der oben beschriebene Fix für das IE8/Opera-Problem?

Ja, und für das Safari-Problem.

So, mit

  
* html #contentFrame {  
    height: 1%;  
    margin-right: -3px;  
}  

und dem Entfernen des margins hab ich jetzt alles wunderbar zum Laufen bekommen.

Nochmal vielen Dank für die Hilfe!