Freigeben über


Webseiten Umstieg auf IE9–aber wie?

 

Jetzt ist der Internet Explorer 9 seit einiger Zeit verfügbar und eigentlich sprechen die Features, die Performance und natürlich auch die Security klar für das Ablösen des aktuellen Browsers durch den Internet Explorer 9.

Aber manchmal ist dies leichter gesagt als getan und daher möchten wir heute ein wenig Hilfestellung bei dem allgemeinen Vorgehen liefern.

Zu allererst muss natürlich verstanden werden, welche Probleme sich überhaupt ergeben können und wie diese zu Lösen sind.

Die Hauptprobleme kommen dadurch zustande, dass insb. ältere Anwendungen speziell für eine Browserversion optimiert wurden und diese dadurch nicht in anderen Browsern korrekt/vollständig funktional sind.

Daraus ergibt sich vor allem folgende Problemseiten/anwendungen:

  1. Seiten die für IE6 gebaut wurden
  2. Seiten die für IE7 gebaut wurden
  3. Seiten die für IE8 gebaut wurden

Hier gibt es je nach Problempunkt nun verschiedene Möglichkeiten.

Die für alle Punkte mögliche, aber auch aufwändigste – sowohl Zeit wie auch Geld -  ist es die bestehende Anwendung für den Internet Explorer 9 umzubauen, bzw. besser auf einen Standard wie HTML5 zu bringen. Da dies zumindest für eine möglichst schnelle Umstellung auf IE9 keine Lösung darstellt, hier im Einzelnen genauere Informationen zu 1.-3.:

zu 1.: Seiten, die dediziert für IE6 optimiert wurden, stellen das größte Hindernis dar, da diese durch den inzwischen hoffnungslos veralteten Browser (also hauptsächlich dessen Rendering und Javascript Engine) oft sehr speziell auf Eigenarten des IE6 getrimmt wurden. Diese Eigenarten wurden über die nachfolgenden Internet Explorer Versionen zunehmend entfernt und der Internet Explorer wurde spätestens mit IE8 “standardkonform”.

Zu aller erst muss also überprüft werden, ob und wenn ja in welchem Maße, die Optimierungen tatsächlich Auswirkungen auf das Verhalten bei der Verwendung mit IE8/9 haben.

Dazu müssen zwei Dinge getan werden: a) Sichtprüfung und b) Funktionsprüfung. Ggf. müssen dabei sog. “Browserweichen” vorher (!!) entfernt werden, da diese oftmals ungünstig erstellt wurden und z.B. nur überprüfen “IF ==IE6” und nicht “IF >= IE6”.

Anschließend kann z.B. mittels der “Super Preview” die Sichtprüfung durchgeführt werden und basierend darauf muss das Design der Anwendung angepasst werden.

Parallel (oder danach Zwinkerndes Smiley ) sollte auch ein umfangreicher Funktionstest durchgeführt werden, denn grade auch bei Javascript Funktionen hat es in den letzten 11 Jahren (sprich seit IE6) ein paar Änderungen gegeben. Wichtig bei dem Funktionstest ist, dass hier u.U. mit dem (manuellen) Ändern des “Document Modus” sogar Abhilfe geschaffen werden kann, ohne dass auch nur eine Zeile Code angefasst werden muss. Wenn man sehr viel Glück hat, kann hierdurch u.U. sogar auch ein Design Problem gelöst werden. Der dem IE6 ähnlichste Document Modus ist der “Quirks” oder auch “IE5” Modus, sprich mit diesem sollte zuerst getestet werden.

Basierend auf den Ergebnissen müssen dann entsprechende Maßnahmen auf Code-Level ergriffen werden. Dabei sollte darauf geachtet werden, dass Standard Konform gearbeitet wird. (HTML4&CSS2.1 oder evtl. sogar schon HTML5&CSS3 – auch wenn HTML5 und CSS3 noch keine verabschiedeten Standards sind und hier u.U. noch Änderungen am Standard vorgenommen werden und man sich dadurch in Gefahr begibt, dass eine solche Anwendung erneut angefasst werden müsste) 

 

zu 2.: Sowohl in IE8 wie auch in IE9 ist der sog. “Kompatibilitätsmodus” enthalten, welcher die Rendering UND (!!) die Javascript Engine auf IE7 zurückstellt. Dieser Modus ist per default für alle Intranet Seiten aktiv, kann aber auch durch einen Entwickler, den Serveradmin oder den Domänen Admin eingestellt werden, vgl. hierzu auch: IE8/9: Compatibility View–Wie kann manuell, serverbasiert oder per Policy das Verhalten beeinflusst werden?

zu 3.: Auch dies stellt sich unkritisch dar, denn der IE9 enthält auch einen IE8 Kompatibilitätsmodus, der auf sehr ähnliche Weise genutzt werden kann. Unsere Empfehlung ist übrigens, dass wenn eine (interne) Anwendung für IE8 geschrieben und auch damit getestet wurde, dass dies entsprechend auch in der Anwendung vermerkt wird.

 

Sowohl 2. und 3. muss natürlich auch getestet werden, allerdings dürfte es in den meisten Fällen auch bei diesem Test bleiben, da hier keine Probleme zu erwarten sind [ja, es ist theoretisch denkbar, dass es trotzdem zu unterschiedlichem Verhalten kommt, dies ist aber nur in äußerst seltenen Fällen beobachtet worden]

 

Übrigens: Ich möchte in diesem Zusammenhang darauf hinweisen, dass es “bad design” ist, wenn eine Seite z.B. HTML5 Standard benötigt, aber in einem iframe Quirks oder IE7 Standard benötigen würde – dies kann nur bedingt funktionieren und unsere Empfehlung ist ganz klar, dass auf einer Seite durchgängig ein Modus benötigt werden sollte um jeglichen Problemen im Vorfeld aus dem Weg zu gehen!

 

Außerdem haben meine Kollegen vom IE Dev Team grade den “IE9 Compat Inspector” fertig und kostenlos zur Verfügung gestellt. Dies ist eine Javascript Library, die in eine bestehende Webseite integriert werden muss und auf der Seite die gefundenen Fehler reportet. Wer für den Test nicht extra den Source einer Anwendung anfassen kann oder möchte, der kann dies automatisiert über die Verwendung von Fiddler tun.

 

IE8/9 Compatibility Test Guide–in deutsch

IE8/9: Compatibility View–Wie kann manuell, serverbasiert oder per Policy das Verhalten beeinflusst werden

Best Practice: Anwendungsmigration für IE8/9/…

Super Preview–oder wie mache ich meine Anwendung IE8/9 ready?

"Do No Evil" mit Browserweichen

Preparing Your Site for IE9

IE9 Compat Inspector

Blog Serie: Internet Zonen und Internet Explorer Erweiterte Einstellungen (Advanced Settings) [Updated IE9]

 

Viel Spaß bei der Migration und ein schönes Wochenende

-Stephanus