nicht angemeldet
Layout gut in IE5.x, aber nicht in IE6.0
Hallo,
ich habe vor Kurzem ein Layout gemacht und hier um Browsertests gebeten. Keiner hat einen Fehler entdeckt.
http://forum.de.selfhtml.org/archiv/2004/1/70308/
Jetzt habe ich aber entdeckt, dass IE 6.0 das Design anders interpretiert.
Hier ein Vergleich IE 5.0 zu IE 6.0
<img src="http://www.landshut.org/bnla01/members/mex/swolfgang/IE5_0.jpg" border="0" alt=""> <img src="http://www.landshut.org/bnla01/members/mex/swolfgang/IE6_0.jpg" border="0" alt="">
sieht aus, als würden die Layer kopf und abschluss schmäler dargestellt.
<img src="http://www.landshut.org/bnla01/members/mex/swolfgang/IE6_0_layout.jpg" border="0" alt="">
Vergleicht man das Ganze stellt sich aber heraus, dass der Layer inhalttext breiter ist und die beiden anderen nicht mitgehen.
<img src="http://www.landshut.org/bnla01/members/mex/swolfgang/vergleich.jpg" border="0" alt="">
Ich konnte nicht viel suchen, da ich nur in der Arbeit einen IE 6.0 zur Verfügung habe und entsprechend nur in der Mittagspause probieren kann.
Soviel habe ich gefunden: ohne Textinhalt zeigt auch IE 6.0 das Layout korrekt. Aber das kann ja kaum Sinn einer Webseite sein keinen Inhalt zu haben ;-)
Wer probieren will kann unter http://www.landshut.org/bnla01/members/mex/swolfgang/layout_neu1.zip alle Quellen herunterladen (ca 26KB).
Grüße
Marcus
-
Hallo,
Hier ein Vergleich IE 5.0 zu IE 6.0
da ist der box-bug naheliegend.
Mit dem Kommentar am Dateianfang sieht es beim IE6 besser aus:
<!-- -->
<!DOCTYPE HTML PUBLIC "-//W....Grüsse
Cyx23
-
Hallo,
da ist der box-bug naheliegend.
Mit dem Kommentar am Dateianfang sieht es beim IE6 besser aus:
<!-- -->
<!DOCTYPE HTML PUBLIC "-//W....Danke jetzt macht ers richtig.
Gibts zu dem box-bug weitere Infos (wann wo warum)?Grüße
Marcus-
Hi,
Danke jetzt macht ers richtig.
Gibts zu dem box-bug weitere Infos (wann wo warum)?ich vermute, daß es jedoch nicht am normalen Box-Modell-Bug des IE gelegen hat. Denn dann müßte es (da ich keine Anpassungen für den IE entdecken kann) genau anders herum sein: IE6 im standards-compliant mode, Mozilla &Co müßten es korrekt anzeigen und IE5 falsch. Daher hast Du es vermutlich mit einen neuen Bug des IE6 zu tun.
Wie auch immer, umschalten in den quirks-mode hat ja wohl geholfen. Infos hierzu z.B. direkt von der Quelle:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.aspfreundliche Grüße
Ingo
-
-
-
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
-
Hallo zusammen,
falls nach der Analyse von Mathias eine punktgenaue Anpassung mit anspruchsvollem Rendermodus für IE 6 möglich ist, umso besser. Aber die Strategie gerade den IE 6 seinen Un-Fähigkeiten entsprechend zu behandeln und nicht vorrangig einige fehlerhaft implementierte CSS-Verbesserungen nutzen zu wollen ist zunächst der zuverlässigere Ansatz.
Um das zu korrigieren, würde ich nicht gleich mit Kanonen auf Spatzen schießen und den gesamten Rendermodus umstellen.
Da wäre der Spatz in dem Fall der beim CSS-kompatiblen Rendermodus überforderte Browser IE 6 und nicht der gesamte Rendermodus.
Der IE 6 verhält sich im BackCompat-Modus, also z.B. nach der Ergänzung im HTML-Code, ähnlich wie die ja immer noch zu berücksichtigenden IE 5 und IE 5.5. Also grundsätzlich beim IE 6 wirklich kein Kanonenschuß, sondern erstmal die zuverlässigste und schonenste Methode dem IE 6 beizukommen wenn es denn hilfreich ist und ihn so laufen zu lassen wie er es besser und stabiler kann, nämlich ähnlich wie seine Vorgänger.
Wenn tatsächlich der IE 6 ohne Hacks und Browserweichen zu einer gleichen Darstellung zu bewegen wäre wie Mozilla und Opera, könnte die grundsätzliche Bewertung anders ausfallen, da wo der IE 6 schließlich besser darstellt als IE 5 ist die Bewertung sowieso anders, und dann gibt es ja genug Browserweichen um notfalls den alten IEs ggf. Nachhilfe zu verpassen.
Grüsse
Cyx23
-
Hallo,
die Strategie gerade den IE 6 seinen Un-Fähigkeiten entsprechend zu behandeln und nicht vorrangig einige fehlerhaft implementierte CSS-Verbesserungen nutzen zu wollen ist zunächst der zuverlässigere Ansatz.
Pauschal kenne ich dazu keinen Grund, das würde ich immer an konkreten Anforderungen entscheiden.
Um das zu korrigieren, würde ich nicht gleich mit Kanonen auf Spatzen schießen und den gesamten Rendermodus umstellen.
Da wäre der Spatz in dem Fall der beim CSS-kompatiblen Rendermodus überforderte Browser IE 6 und nicht der gesamte Rendermodus.
Der IE 6 verhält sich im BackCompat-Modus, also z.B. nach der Ergänzung im HTML-Code, ähnlich wie die ja immer noch zu berücksichtigenden IE 5 und IE 5.5. Also grundsätzlich beim IE 6 wirklich kein Kanonenschuß, sondern erstmal die zuverlässigste und schonenste Methode dem IE 6 beizukommen wenn es denn hilfreich ist und ihn so laufen zu lassen wie er es besser und stabiler kann, nämlich ähnlich wie seine Vorgänger.
Der Punkt hier war, dass das nicht die Ursache beseitigt. Und diese Ursache ist nicht nur im MSIE 6 problematisch, dieser macht nur teilweise etwas falsch. Auch in anderen Browsern gibt es diese Überlappung, die unter Umständen zum Problem werden kann (das müsste man natürlich haarklein austesten, um das oder das Gegenteil zu behaupten). Der Code ist in dieser Form m.E. nicht zuverlässig und die Symptome im MSIE 6 zu umgehen, halte ich eher für das kleinere Problem. Da der IE 6 hier im standardkonformen Modus ansonsten keine Probleme hat bzw. zu haben scheint, sehe ich die konkrete Auswirkung des »besser und stabiler« nicht, daher finde ich es nicht nachhaltig, den Weg über den Rendermodus zu wählen, aber das müsste man natürlich konkret untersuchen.
Wenn tatsächlich der IE 6 ohne Hacks und Browserweichen zu einer gleichen Darstellung zu bewegen wäre
Hier konkret gab es doch m.W. keine weiteren Probleme.
wie Mozilla und Opera, könnte die grundsätzliche Bewertung anders ausfallen, da wo der IE 6 schließlich besser darstellt als IE 5 ist die Bewertung sowieso anders, und dann gibt es ja genug Browserweichen um notfalls den alten IEs ggf. Nachhilfe zu verpassen.
Klar, ich wollte auch nichts grundsätzlich bewerten. Meine grundsätzliches Urteil ist, nicht grundsätzlich urteilen. ;)
Mathias
-
Hallo Mathias,
Pauschal kenne ich dazu keinen Grund, das würde ich immer an konkreten Anforderungen entscheiden.
'Pauschal' muss natürlich nicht sein, aber pauschal lässt sich schon feststellen dass ein kleinster gemeinsamer Nenner und defensives Verhalten beim Cross Browser behandeln weniger Probleme verusacht.
So ist auch der doctype-switch usw. für den IE 6 per normaler Codierung pauschal harmloser als ein 'Hack'.Der Punkt hier war, dass das nicht die Ursache beseitigt. Und diese Ursache ist nicht nur im MSIE 6 problematisch, dieser macht nur teilweise etwas falsch. Auch in anderen Browsern gibt es diese
Vielleicht hast du Recht, ich hatte letztendlich die Ursache einfach darin gesehen dass der IE 6 den CSS-Modus eben nicht beherrscht.
Klar, ich wollte auch nichts grundsätzlich bewerten. Meine grundsätzliches Urteil ist, nicht grundsätzlich urteilen. ;)
Wir benötigen ja Vorausurteile um arbeiten -oder ökonomisch arbeiten- zu können.
Gerade da ist es m.E. wichtig eine Bevorzugung von "fortschrittlichem" oder "modernem" Code um den Preis nachfolgender Mängel und Klimmzüge zu hinterfragen, und deine Einschätzung als "Kanone" schien mir in die falsche Richtung zu gehen.
Beispielsweise bei einer grundsätzlichen Entscheidung zum Verzicht auf Hilfs- und Containerdivs steht dann den u.U. nötigen CSS-Spielereien immerhin ein sehr aufgeräumter HTML-Code als Nutzen gegenüber. Hier beim IE 6 sehe ich hingegen erstmal zu wenig Vorteile durch den anspruchsvolleren Rendermodus, im Gegenteil wird der IE z.B. bei (allerdings nicht empfehlenswerten) dhtml/expression instabil, und kann meist doch nicht richtig rendern. Wenn also die naheliegende Idee zukunftsorientiert alle modernen Browser gleich zu behandeln zum einen doch (womöglich mehr) Korrekturen für alte IEs erfordert, und der IE 6 auch noch Extrawürste benötigt, ergibt sich aus der Summe der Korrekturen ein Vorteil für den IE 6 im BackModus. Wobei mir eigentlich ein IE6 im CSS-kompatiblen Modus lieber ist, doch eine nüchterne Bewertung scheint m.E. immer noch zugunsten back-compatible auszugehen.
Grüsse
Cyx23
-
Hallo,
Pauschal kenne ich dazu keinen Grund, das würde ich immer an konkreten Anforderungen entscheiden.
'Pauschal' muss natürlich nicht sein, aber pauschal lässt sich schon feststellen dass ein kleinster gemeinsamer Nenner und defensives Verhalten beim Cross Browser behandeln weniger Probleme verusacht.
Ich sehe immer noch keine Kriterien, an denen sich das festmachen ließe, außer eben das nicht belegbare »Gefühl«, MSIE 6 nicht herauszufordern (so stellt es sich für mich zumindest dar, wenn auf einer solchen abstrakten Ebene für das eine oder andere Vorgehen argumentiert wird). Gut, ich habe nicht die Erfahrung, dass nach zahllosen Layoutumsetzungen zu der Erkenntnis gekommen bin, dass eine bestimmte Strategie statistisch-tendenziell gesehen die bessere war, aber selbst wenn ich diese hätte, würde ich nicht bei der nächsten Aufgabe wie bei der Mehrheit der vergangenen Fälle handeln, ohne mir die konkreten Anforderungen anzuschauen. Wenn man jede neue Seite für MSIE 5.x, 6 und Opera 7 im Kompatibilitätsmodus schreibt, ohne sich weiter zu kümmern, läuft es früher oder später auf Kontrollverlust hinaus, da man sich nicht mehr bewusst ist, welche Fehler überhaupt durch den Rendermodus behoben werden und welche im anderen auftauchen würden. Wenn man sich ständig bewusst darüber ist, welche Folgen diese Entscheidung hat und haben wird, bestünde dieses Problem natürlich nicht, nur sind diese wohl in der Regel nicht in ihrer Gesamtheit erfassbar.
So ist auch der doctype-switch usw. für den IE 6 per normaler Codierung pauschal harmloser als ein 'Hack'.
Wieso? (Und warum ist dies kein »Hack«?)
Wir benötigen ja Vorausurteile um arbeiten -oder ökonomisch arbeiten- zu können.
Das mag sein, ich finde es nur schade, wenn die Untersuchung zu kurz kommt und die Zusammenhänge im Ungewissen bleiben. Erst wenn ich mir all dieser Zusammenhänge bewusst bin - was natürlich voraussetzt, einer Sache auf den Grund zu gehen -, kann ich ein Vorurteil bilden, das letztlich irgendwann nach genügend Anpassungen hinreichend verlässliche Resultate liefert.
Gerade da ist es m.E. wichtig eine Bevorzugung von "fortschrittlichem" oder "modernem" Code um den Preis nachfolgender Mängel und Klimmzüge zu hinterfragen, und deine Einschätzung als "Kanone" schien mir in die falsche Richtung zu gehen.
Ich sehe nichts Falsches daran, einen Renderfehler zuerst zu lokalisieren, bevor man sich umsieht, wie sich dem begegnen lässt. Und vom jeweiligen Fix möchte ich mir sicher sein, alle jeweiligen Auswirkungen (hinreichend) vorhersagen zu können. Und wenn ich wegen eines solchen kleinen Fehlers den gesamten Rendermodus ändere bzw. bewusst setze, während es vorher egal war, dann mag das sinnvoll sein, wenn ich dadurch auch gleich andere Fehler bewusst umgehe, denen sonst nur durch grässliche Einzelhacks begegnet werden könnte. Wenn eine punktuelle Behandlung möglich ist, ziehe ich diese vor, da die Konsequenzen dessen m.E. einfacher vorhersehbar sind.
Beispielsweise bei einer grundsätzlichen Entscheidung zum Verzicht auf Hilfs- und Containerdivs steht dann den u.U. nötigen CSS-Spielereien immerhin ein sehr aufgeräumter HTML-Code als Nutzen gegenüber. Hier beim IE 6 sehe ich hingegen erstmal zu wenig Vorteile durch den anspruchsvolleren Rendermodus, im Gegenteil wird der IE z.B. bei (allerdings nicht empfehlenswerten) dhtml/expression instabil, und kann meist doch nicht richtig rendern. Wenn also die naheliegende Idee zukunftsorientiert alle modernen Browser gleich zu behandeln zum einen doch (womöglich mehr) Korrekturen für alte IEs erfordert, und der IE 6 auch noch Extrawürste benötigt, ergibt sich aus der Summe der Korrekturen ein Vorteil für den IE 6 im BackModus.
Wenn diese Voraussetzungen tatsächlich gegeben sind, bezweifle ich das gar nicht. Aber ohne sich überhaupt zu konkret zu fragen, welche Extrawürste nötig wären, lässt sich gar nicht erst in Erfahrung bringen, ob diese Voraussetzungen gegeben sind.
Wobei mir eigentlich ein IE6 im CSS-kompatiblen Modus lieber ist, doch eine nüchterne Bewertung scheint m.E. immer noch zugunsten back-compatible auszugehen.
Was ist daran eine »nüchterne Bewertung«? Die Diskussion führen wir nicht zum ersten Mal und bisher nanntest du keine rationalen Gründe, die es ohne nähere Betrachtung der Umstände nahelegen, MSIE 6 grundsätzlich zuerst einmal im Kompatibilitätsmodus zu bedienen und auf dieser Grundlage aufzubauen. Das mag deine Erfahrung sein und als solche gerechtfertigt sein, ich kann sie aber nicht nachvollziehen, da ich Vor- und Nachteile nicht vollkommen abstrahiert abwägen kann.
Mathias
-
Hallo,
[..] nach zahllosen Layoutumsetzungen zu der Erkenntnis gekommen bin,
und selbst da wäre noch der persönliche Stil als Einfluß zu berücksichtigen.
[..] für MSIE 5.x, 6 und Opera 7 im Kompatibilitätsmodus schreibt,
Hier geht es (nur) um Quirks für den IE 6.
Wieso? (Und warum ist dies kein »Hack«?)
Wie wäre es z.B. damit (der unschöne Effekt i.d. ersten Zeile bei alten Browsern ist mir bekannt, deswegen ist z.B. <!-- --> interessant ):
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">Was ist daran eine »nüchterne Bewertung«? Die Diskussion führen wir nicht zum ersten Mal und bisher nanntest du keine rationalen Gründe, die es ohne nähere Betrachtung der Umstände nahelegen, MSIE 6 grundsätzlich zuerst einmal im Kompatibilitätsmodus zu bedienen und auf dieser Grundlage aufzubauen.
Dass u.U. alle IE mit gleichem Code bedient werden können ist ein nachvollziehbarer Vorteil, und dass umgekehrt der IE 6 als CSS1-kompatibel oft nicht überzeugt ist auch nachvollziehbar. Auch die Möglichkeit u.U. mit nur einer Weiche auskommen zu können ist erstmal vorteilhaft, ggf. können ja IE 4 und Netscape 4 den gleichen Code mit gleicher Weiche erhalten.
Wie diese Vorteile gewichtet werden hängt natürlich vom Einzelfall ab, angesichts der vielen Möglichkeiten im CSS oder z.B. per conditional comment empfinde ich es durchaus als konsequent und auch bei der CSS-Anpassung komfortabel den IE 6 auch CSS1-kompatibel rendern zu lassen.
Dabei tauchen dann allerdings immer wieder die Grenzen dieser Gleichbehandlung (wie Mozilla /Opera) auf, dazu auch die manchmal nötigen Anpassungen an die verschiedenen IEs.
Dass eine Trennung in IE-Windows, IE 6 dabei Back-compatibel, und Mozilla/Opera schon wegen der Übersichtlichkeit eine mögliche und konsequente Strategie darstellt wird m.E. durch die Begleitumstände anderer Vorgehensweisen ebenso bestätigt wie durch die oft geringere Zahl an Korrekturen.
Um nun die von dir geforderten "rationalen Gründe" weiter zu entwickeln müsste erstmal gefragt werden ob überhaupt eine Strategie nötig ist, ob etwa für Anfänger Empfehlungen angebracht sind, und welches Ziel dabei verfolgt wird; eine Vorgehensweise welche gutmütiger auf eine unvollständige (IEs) Testumgebung reagiert halte ich grundsätzlich nicht automatisch für richtiger, aber durchaus für empfehlenswert.Grüsse
Cyx23
-
-
-
-
-
Hallo,
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.
Danke, das ist einleuchtend, dann weise ich denen doch ganz einfach 100%-15px zu ;-)
Na gut, vielleicht formatiere ich die Links im Mittelteil einfach anders. Jetzt weiß ich ja was ich falsch gemacht habe.
Grüße
Marcus
-