IE 8 Quirks vs Standards retrieving OffsetHeight/offsetWidth

Ich bin dabei, meine Anwendung in XHTML-strict-Modus zu konvertieren (es hatte zuvor noch keinen DOCTYPE). Allerdings bemerkte ich eine deutliche Verschlechterung, wenn OffsetHeight/OffsetWidth erhalten. Dies ist bei Seiten mit einer großen Anzahl von DOM-Elementen sehr auffällig, sagen wir mal eine Tabelle mit 1 Spalte mal 800 Zeilen, die Zellen haben nur ein Stück Text. Das Besuchen jedes untergeordneten Elements in dieser Tabelle, um ihre Offset-Dimension zu erhalten, ist viel langsamer als wenn der IE die Seite im Quirks-Modus rendert. Warum ist das der Fall? und weiß jemand Tipps, um IE zu helfen, diese Offsetwerte zu berechnen?IE 8 Quirks vs Standards retrieving OffsetHeight/offsetWidth

Quelle

2010-08-21 Paul

Haben Sie irgendwelche Proben, um dies zu demonstrieren? – lincolnk

Ich würde vorschlagen, IE zu zwingen, Sie Seite im Standardmodus nicht in Macken zu rendern. Dies kann durch Hinzufügen von Meta-Tags am Kopf des HTML-Dokuments oder durch Einrichten des Webservers zum Hinzufügen von X-UA-kompatiblen Headern erfolgen.

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

Auch Verwendung integrierte JavaScript-Frameworks wie jQuery, Prototype, YUI, etc, die meisten von ihnen werden bereits die Probleme auf verschiedenen Rendering-Engines gerichtet.

Quelle

2010-08-23 04:22:00 jerjer

Ich stimme zu, dass Frameworks viel helfen. Ich habe kürzlich in einem Projekt festgestellt, dass IE 8 immer noch das falsche '$(). OuterHeight()' meldet. Es hat mich verrückt gemacht! Es schien, dass IE versuchte, die Höhe zu erreichen, während die Größe der Elemente geändert wurde, also musste ich etwas synchronisieren. Dies war nur ein Problem auf IE 8, so dass es einige Zeit brauchte, um zu finden. –

Mein Problem kann nicht im Standardmodus gerendert werden. Das Problem tritt auf, wenn meine Seite im Standardmodus gerendert wird. Ich isolierte das Problem tatsächlich auf eine Codezeile. Die problematische Zeile war: element.absoluteHeight=element.offsetHeight; Ich nahm fälschlicherweise an, dass es die Offset-Dimension, wo das Problem war, bekam, da ich so viel über Browser-Reflow gelesen hatte. Sobald ich jedoch diese Zeile durchbrochen habe, wird die Einstellung für die Eigenschaft auf dem DOM-Element aktiviert, wo es einen großen Leistungsunterschied zwischen den Eigenarten und dem IE8-Standardmodus gibt, wobei der letztere Modus viel schlimmer ist. – Paul

@Paul: Kannst du das beantworten? Ich kann dies reproduzieren: Die meisten Operationen sind im IE8-Standards-Modus viel schneller, einschließlich des Lesens der Offset-Dimensionen. Expandos sind jedoch langsam. – bobince

@bobince: Das Problem, das ich glaube, ist um Reflow. Die Logik in meinem JavaScript versucht herauszufinden, ob sich Kinder in einem absoluten Layout-Container überlappen (da sie dynamischen Inhalt bekommen, den ich nicht vorhersagen kann) und passt dann die CSS-Dimensionen des Elterns und die CSS-Werte der Eltern an, die heruntergeschaltet werden müssen. Das Ändern der css-Dimensionen löst einen Reflow aus und dies geschieht mitten in meiner Iteration. Dieses Szenario scheint in IE8-Standards viel langsamer zu sein als in IE8-Quirks für sehr große Tabellen. Ich weiß, dass ich DocumentFragment bei dieser Art von Operationen verstecken oder verwenden sollte, da ich jedoch Dinge zum Verschieben brauche und dann die neuen Versatzdimensionen betrachten möchte, erhielt ich ungenaue Werte.

Quelle

2010-08-28 02:11:17 Paul

IE 8 Quirks vs Standards retrieving OffsetHeight/offsetWidth

Antwort

Verwandte Themen