Anhang 1: Internet Explorer 6 zu Internet Explorer 8 Browseränderungen

In der folgenden Tabelle werden Änderungen zwischen Microsoft Internet Explorer 6 und Windows Internet Explorer 8 beschrieben.

Entwurfsänderungen von Internet Explorer 6 auf Internet Explorer 7

Entwurfsänderungen von Internet Explorer 7 auf Internet Explorer 8

${ROWSPAN2}$Internet Explorer Versionsverwaltung${REMOVE}$

Suchen Sie nach Code, der fälschlicherweise Sonderfälle um Internet Explorer 6, Windows Internet Explorer 7 oder Internet Explorer 8 bis Benutzer-Agent-Zeichenfolgen mit Iffing, Versionsvektoren oder bedingten Kommentaren.

• Wenn eine lange Benutzer-Agent-Zeichenfolge (UA) auf einen Server trifft, der nur kürzere UA-Zeichenfolgen akzeptiert, wird benutzern eine Fehlerseiteangezeigt.

• Die Kompatibilitätsansicht in Internet Explorer 8, die standardmäßig für Intranetwebsites aktiviert ist, sendet eine Internet Explorer 7 Benutzer-Agent-Zeichenfolge. Um zwischen Internet Explorer 7 und der Kompatibilitätsansicht zu unterscheiden, suchen Sie nach dem neuen Trident-Token.

${ROWSPAN3}$ Complianceupdates für Standards

• Gilt für angegebenen Dokumentmodi.
• Internet Explorer 8 Kompatibilitätsansichtsmodus, der standardmäßig für Intranetwebsites aktiviert ist, Revertiert Standardupdates von Internet Explorer 7 auf Internet Explorer 8.
• Verwenden Sie den EmulateIE7 X-UA-kompatible HTTP-Header oder Meta--Element, um die Kompatibilitätsansicht auf Websites oder bestimmten Webseiten zu aktivieren.

${REMOVE}$

Ausnahme im Quirksmodus: Sie müssen keine Standardcomplianceänderungen für Webseiten vornehmen, die den Quirksmodus DOCTYPE angeben (indem Sie die DOCTYPE-Option "Standards-Compliance" auf "aus" festlegen).

Gilt für Internet Explorer 7 Standards oder den Modus "Streng" und höher:

• XML-Prologs in der ersten Zeile des Quellcodes führen nicht mehr dazu, dass DOCTYPE-Deklarationen fehlschlagen.
• Box-Modell Überlaufinhalt überschneidet sich das Feld und -grows das Feld div nicht mehr automatisch, um den Inhalt anzupassen.
• Bestimmte CSS-Filter (z. B. *HTML, _underscore und /**/ Kommentar) werden nicht unterstützt.
• Nur das äußerste OBJECT-Element in geschachtelten Objekten instanziiert wird.
• Applications, die auf dem SELECT-Element basieren um einen HWND abzurufen, der mit Microsoft Win32-APIs verwendet werden kann, kann nicht mehr verwendet werden, da das SELECT-Element jetzt ein fensterloses Steuerelement ist.
• Kanaldefinitionsformat (CHANNEL Definition Format, CDF) wird zugunsten von RSS-Feeds nicht unterstützt.
• XBM-wird kein Imageerstellungsformat unterstützt, das für X-basierte Systeme entwickelt wurde.
• BASE-Tags außerhalb des HEAD-Dokuments sind nicht zulässig.

Gilt für Internet Explorer 8 Standards-Modus und höher:

• Nicht gesperrte P-Elemente werden automatisch geschlossen, wenn sie auf TABLE, FORM, NOFRAMES-oder NOSCRIPT--Elemente folgen.
• falsch formatierte HTML- wird nicht unterstützt, zugunsten wohlgeformter, gültiger Markups.
• Das Attribut "className" Syntax wird nicht unterstützt, zugunsten der "Klassensyntax".
• Die Attributes-Auflistung enthält nicht alle möglichen Attribute, die Windows Internet Explorer erkennt.
• Attributsortierung hat sichgeändert, was sich auf die Attributeauflistung, innerHTML und outerHTML auswirkt.
• "GetElementById"- die Groß-/Kleinschreibung beachtet und keine Namensattribute durchsucht.
• generische CSS-Präfixselektoren (d. h. v\:* Syntax) werden zugunsten expliziter Tagnamen nicht unterstützt.
• CSS-Ausdrücke werden nicht unterstützt, zugunsten einer verbesserten CSS-Unterstützung oder DHTML-Logik.
• Code, der für benutzerdefinierte JSON-Objektmethoden vorgesehen ist, kann mit dem new native JSON-Objekt in Internet Explorer 8 in Konflikt stehen.
• Nicht festgelegte anfangseigenschaften für das currentStyle-Objekt geben ihren Anfangswert zurück.
• Nicht angegebene Eigenschaftenwerte für das currentStyle-Objektformatvorlagenobjekt geben eine leere Zeichenfolge zurück (siehe z. B. den Blogbeitrag "ASP.NET Menu" und "IE8 rendering white issue ").

• Aktualisieren Sie ARIA-Syntax in allen Internet Explorer Renderingmodi für Websites und Anwendungen, bei denen die Barrierefreiheit ein Problem darstellt.
• Überprüfen Sie die Liste Vervollständigen der CSS-Updates von Internet Explorer 6 bis Internet Explorer 8.

Verbesserungen der Sicherheit

• Gilt unabhängig vom Dokumentmodus.
• Sie können Sicherheitsfeatures mithilfe Gruppenrichtlinien-deaktivieren.

• Die window.opener- Umgehung der Eingabeaufforderung "window.close" ist nicht zulässig.
• Objektzwischenspeicherungsschutz ist standardmäßig aktiviert, wodurch der Zugriff auf Verweise von Objekten blockiert wird, wenn Benutzer zu einer neuen Domäne navigieren (gilt für Internet Explorer 6 und höhere Versionen auf Windows XP mit Service Pack 2 (SP2) und höheren Versionen).
• DHTML-Skriptlets standardmäßig deaktiviert sind.
• Skripts, die in die Statusleiste schreiben, blockiert werden.
• URL-Erstellung schlägt möglicherweise fehl, wenn URLs nicht RFC-Richtlinien erfüllen.
• HTTPS-Seiten zeigen eine Fehlerseite an, wenn die Website nur für SSLv2 konfiguriert ist oder wenn das Websitesicherheitszertifikat veraltet oder ungültig ist, Fehler aufweist oder schwache Verschlüsselungen aufweist.
• Nur "Punycode" codierte internationalisierte Domänennamen werden unterstützt. Andere Formate wie ANSI und UTF-8 werden blockiert.
• domänenübergreifende Skript-URLs, umgeleitete Navigation in DOM-Objekten und Framenavigationen werden blockiert.
• modale oder moduslose Dialogfelder, die aus dem Skript erstellt werden, können etwas größereerscheinen.
• unsicheren Protokolle Ansichtsquelle, Gopher (auf WinINET-Ebene) und Telnet funktionieren nicht.

• XSS-Filter- ist standardmäßig aktiviert, wodurch Skriptmuster blockiert werden, die am häufigsten Typ-1-XSS-Angriffen ähneln, es sei denn, Sie deaktivieren sie über einen X-XSS-Protection HTTP-Header.
• Domänenübergreifende, dokumentübergreifende Kommunikationshacks wie SCRIPT SRC- werden nicht unterstützt, zugunsten sichererer XDM- und XDR AJAX-Features.
• AJAX-fähige Websites, die den Hash der URL manuell bearbeiten können durch die neue window.location.hash-Navigationseigenschaft beschädigt werden.
• Neuen AJAX-Features wie XDM-systemeigene Eigenschaften, die möglicherweise mit vorhandenen benutzerdefinierten Eigenschaften in Konflikt stehen.
• Dateiupload-Steuerelement sendet nur den Dateipfad, nicht den vollständigen Pfad, an den Server.
• HTML-Code oder Skript, der mit einem "image/*" MIME-Typ bereitgestellt wird, nicht ausgeführt werden.
• Navigieren in einem Frame auf oberster Ebene zu einer Website in einem anderen Sicherheitskontext öffnet ein neues Fenster oder eine neue Registerkarte, anstatt innerhalb des vorhandenen Frames zu navigieren.
• UTF-7-codiertes Skript wird in Windows-1252-Codierung erzwungen, was dazu führen kann, dass nur-Text gerendert wird.
• HTTP/HTTPS-Seiten "gemischter Modus" ein Dialogfeld anzeigen, das standardmäßig nur sichere Elemente anzeigt (im Vergleich zum vorherigen nicht unsicheren Standard). Benutzer können versehentlich http-Elementeblockieren, z. B. Schlüsselbilder.
• DEP/NX ist standardmäßig aktiviert, die bestimmte Add-Ons (d. h. ActiveX-Steuerelemente und COM-Objekte) blockiert, die mit älteren Versionen von ATL erstellt werden, indem Code ausgeführt wird, der als "nicht ausführbare Datei" im Arbeitsspeicher gekennzeichnet ist.
• Inhalt, der von einem Webproxy zurückgegeben wird, blockiert wird, wenn kein SSL-Tunnel als Reaktion auf eine CONNECT-Anforderung an den ursprünglichen Server eingerichtet wird.

Architekturänderungen

• Gilt unabhängig vom Dokument- oder Kompatibilitätsmodus.

• geschützte Modus ist standardmäßig für Internet-, Intranet- und eingeschränkte Sites-Zonenaktiviert. Dieser Modus blockiert Browsererweiterungen, die ein Sicherheitsrisiko darstellen können beim Ausführen und lower-Berechtigungsanwendungen auf höhere Rechteprozesse zugreifen, z. B. das Startmenü, Control Panel und die Microsoft Windows Registrierung (gilt für Internet Explorer 7 und höhere Versionen für Windows Vista und höhere Versionen).

• Update des geschützten Modus: Intranet wird standardmäßig in mittlerer (anstelle niedriger) Integritätsebene ausgeführt.
• Loosely Coupled Internet Explorer können Add-Ons (d. h. ActiveX-Steuerelemente und COM-Objekte) blockieren, die eine der folgenden Aktionen ausführen:
  • Verwenden Sie Windows-Hierarchietechniken, um Benutzeroberflächenframe- und Registerkartenfenster zu finden (die jetzt in separaten Prozessen auf unterschiedlichen Integritätsebenen ausgeführt werden).
  • Erstellen Sie eine Unterklasse des UI-Frames (jetzt auf mittlerer Integritätsebene) aus einem Registerkartenprozess mit niedriger Integrität.
  • Verwenden Sie nicht unterstützte Messaging-Techniken zwischen UI-Frame und Registerkarten.

Zugehörige Themen

Anwendungskompatibilität beim Migrieren zu Internet Explorer 8