nicht angemeldet
Hallo,
Vergleicht man das Ganze stellt sich aber heraus, dass der Layer inhalttext breiter ist und die beiden anderen nicht mitgehen.
Ja. Und zwar liegt das genauer gesagt am width:99%; für .navcontainer3 ul li a. Das interpretiert MSIE 6 relativ zur Breite des #inhalttext. width:~100% plus padding-left:15px ergeben 100%+15px. Dadurch erklärt sich, warum #inhalttext genau 15 Pixel breiter ist.
Damit macht MSIE auch nichts grundsätzlich falsch, denn Opera und Mozilla machen dasselbe, mit einem kleinen aber ausschlaggebenden Unterschied: bei ihnen ragt das a-Blockelement aus dem Elterncontainer #inhalttext hinaus und in den margin-right von #inhalttext hinein. Wäre dieser margin-right nicht, würde es aus #mitte herausragen und die Links lägen dann teilweise unter #menue_rechts (habe ich in den Screenshots ausgeblendet). Das siehst du, wenn du #inhalttext, .navcontainer3 ul li und .navcontainer3 ul li span Rahmen gibst:
<img src="http://molily.de/temp/pfarr-moz.png" border="0" alt=""> <img src="http://molily.de/temp/pfarr-op.png" border="0" alt="">
Um das zu korrigieren, würde ich nicht gleich mit Kanonen auf Spatzen schießen und den gesamten Rendermodus umstellen. Nun ließe sich natürlich ganz einfach width:99%; w\idth:auto; schreiben (Simplified Box Model Hack), damit würden Browser über MSIE 5.x die Angabe ignorieren.
Aber es hängt ja mit display:block zusammen. Dies hattest du ja eingefügt, damit das padding-left für a im IE 5.x funktioniert. Jetzt schrieb Thomas im Ursprungsthread:
»IE 5.x 5.x ignoriert padding bei Inline-Elementen nur dann nicht, wenn diese Angaben zu width und/oder height haben.«
Wieso wäre also display:block nötig, wenn width:99%; bereits dazu führen würde, dass 5.x das padding-left anwendet? (Ist es so, ich kann es nicht prüfen?) Der Vorteil wäre, dass MSIE 6 im standardkonformen Modus und andere Browser die width-Angabe einfach ignorieren würden, weil das a-Element ein Inline-Element ist. So würdest du ohne Hack auskommen können, falls diese Annahmen zutreffen.
Mathias