Diese Limitierungen gelten für alle IE-Versionen auch für die Version 9.

Bis einschließlich IE7 bricht die Browserengine das Parsen der Regeln ab 227 KB Dateigröße ab. Diese werden zwar geladen aber nicht mehr verarbeitet.

Ähnliche Artikel

• Effizientes Cross-Browser-Development
• Quick and Dirty: Viel Info, wenig Text
• Der Internet Explorer 9 ist da

Zum Download

Ähnliche Artikel

• Quick’n'Dirty: Stylesheet Limits im IE
• Effizientes Cross-Browser-Development

Sowohl privat als auch beruflich werde ich – wie auch viele andere – ständig mit dem Thema Cross-Browser-Optimierung von webbasierten Anwendungen konfrontiert. Oder wie ich es nenne: Die IE-Suboptimierung *fg*

Leider fallen die Tests zu oft viel zu knapp aus. Das sieht man immer schön daran, dass die Seiten im IE entweder in der Darstellung oder in Sachen Funktion von anderen Browsern abweicht. Und spätestens wenn das dem Kunden auffällt, ist das wirklich kritisch.

In diesem Artikel möchte ich euch kurz erklären, wo die Probleme beim Testen liegen und wie man die Cross-Browser-Optimierung von Websites oder webbasierten Anwendungen effizienter gestalten kann.

Zuerst die Frage: Warum wird so wenig getestet bzw. welche Gründe hat es, dass die Cross-Browser-Qualität (keine Ahnung ob das so heißt, aber ich nenne es mal so ) vieler Projekte nicht den Anfoderungen entspricht?

Nun, dass die Tests so knapp ausfallen hat viele Gründe:

1. macht es keinen Spaß. Um genau zu sein, ist das Testen des Projekts in anderen Browsern als seinen persönlichen Liebling (Firefox, Opera, Chrome, Links, …) wahrscheinlich der unangenehmste Teil am Entwickeln. Einfach weil man schon vorher weiß, dass das, was man entwickelt hat, nicht überall funktionieren wird. Und das obwohl man sich beim Schrieben des Codes schon größte Mühe gegeben hat, auch die Macken des ein oder anderen Browsers zu berücksichtigen. Dennoch gibt es immer wieder Probelme – und besonders im IE 6 und 7 muss man dann sehr viel Zeit investieren um sich mit den Bugs auseinander zu setzen.

   Bei CSS geht das ja noch, da man viel mit "hasLayout" oder "position: relative;" geradebiegen kann, aber spätestens wenn es an den JS-Code geht, wird es hässlich. Das Debuggen im IE 6 und 7 erweist sich oft als so unterhaltend und motivierend wie der Versuch einen IKEA-Bleistieft mit einem Schwingschleifer zu spitzen.

   Dem entsprechend reicht die Motvation der Entwickler, ihre Projekte im Internet Explorer zum Laufen zu bekommen, oft gerade so aus um die VMWare zu booten.

    

2. gibt es eine Deadline. In den meisten Projekten zumindest. Und die lässt es oft nicht zu, dass der Entwickler 50% der Zeit, welche er an dem Projekt arbeitet, damit verbringt den IE zu verfluchen und das Projekt in selbigen zu debuggen.

   Die Tests fallen wegen dem Zeitdruck oft etwas sporadisch aus: Was nicht auf den ersten Blick auffällt bleibt erstmal untentdeckt bis es in der QS-Phase des Projektmanagers auffält oder – im schlimmsten Falle – dem Kunden.

    

3. ist es monotone Routine. Die Abwechslungsreichheit, beim 376. Mal durchklicken des Systems im IE 7 um evtl. doch noch irgendwo einen Fehler zu entdecken, ist etwa so groß wie die der Arbeit, welcher ein Fabrikarbeiter verrichtet, welcher acht Stunden am Tag damit verbringt, Erdnüsse minderer Qualität vom Laufband zu schubsen …

   Durch diese extrem langweilige Routine kommt es sehr schnell zu Flüchtigkeitsfehlern, welche zu Folge haben, dass man eine Layout-Abweichung einfach nicht mehr sieht, weil man diese Seite bereits im Verlauf der letzten 2 Tage im 15-Minuten-Takt immer wieder und wieder aufgerufen hat. Irgendwann nimmt man dabei einfach nichts mehr wahr.

    

4. herrscht zu hohe Komplexität in den Projekten. Oft testet man bestimmte Teile nicht, da man der Ansicht ist, dass sich daran gar nichts geändert haben kann, weil man ja auf einer ganz andern Seite, an einer ganz anderen Datei, an einer ganz anderen Stelle eine Änderung vergenommen hat.

   Die Verbindungen zwischen den Code-Teilen entstehen dann leider oft erst durch Browser-Bugs (gerade bei der Arbeit mit CSS) oder der Entwickler kennt den Zusammenhang zwischen bestimmten Code-Teilen nicht, weil sie einfach zu komplex sind. Das kommt gerade in größeren Projekten mit mehreren Mitarbeitern schnell vor.

   Die Konsequenz ist hier, dass nach Änderungen, bestimmte Teile der Applikation bei dem Test nicht berücksichtigt werden. Klar: Wer hat schon Lust das komplette System nochmal in vier verschiedenen Browsern durchzuklicken nur weil man an einer Stelle ein Margin geändert hat. Man hat ja schließlich eine Deadline und deutlich Besseres zu tun.

    

5. wird zu wenig miteinander gesprochen. In Kombination mit Punkt 4 ist Kommunikation sehr wichtig. Änderungen, die auch nur im Geringsten Teile des Systems betreffen, für die ein anderer Entwickler im Team zuständig ist, sollten demjenigen mitgeteilt werden. Einfach nur damit, Entwickler B weiß, "Hey, da hat sich was in Klasse Xyz geändert, ich sollte Feature abc nochmal testen …".

   Passiert dies nicht, werden evtl. Konsequenzen einer Änderung gerne übersehen: Entwickler A fühlt sich nicht zuständig einen anderen Programmteil als seinen Eigenen zu testen und Entwickler B weiß nichts von der Änderung. Den Rest könnt ihr euch denken.

    

6. ist zu viel Ego im Spiel. Das Aufdecken von Fehlern in der eigenen Anwendung empfinden die viele Entwickler oft als Kritik an Ihren Fähigkeiten. Und genau diese Mitarbeiter können mit Kritik auch nur schwer bis gar nicht umgehen. Sie testen nicht gerne, weil sie sich nicht gerne selbst kritisieren oder sich gerne Fehler eingestehen und nicht einsehen, dass Fehler selbst den Besten Programmierern und Designern passieren.

   Aber diese Entwickler machen keine Fehler, also müssen sie auch nicht testen, entsprechend werden keine Fehler aufgedeckt, und somit wird ihr Ego auch nicht angekratzt. So einfach ist das

Nun stellt sich natürlich die Frage: Wie entwickle und teste ich effizient?

Effizienz bedeutet in diesem Zusammenhang das Aufdecken von möglichst vielen Fehlern in möglichst kurzer Zeit. Dafür ist ein durchdachtes Vorgehen beim Testen, einiges an Erfahrung und die nötige Disziplin, auch beim 200. Durchklicken noch Fehler wahrnehmen zu können, erforderlich.

Ich haber versucht einige Tipps unt Tools zu sammeln, die euch beim Testen und Cross-Browser-Optimieren helfen sollen:

• Ein sehr interessantes Tool, welches ich beim Recherchieren gefunden habe, ist der IETester. Ausprobiert habe ich das Tool nicht, da es das nur für Windows gibt und ich ein Linux-User bin Dennoch klingt die Beschreibung sehr interessant:

  "IETester is a free WebBrowser that allows you to have the rendering and javascript engines of IE9 preview, IE8, IE7 IE 6 and IE5.5 on Windows 7, Vista and XP, as well as the installed IE in the same process."

  Wenn jemand das Tool kennt und/oder ausprobiert hat, darf er gerne ein Kommentar oder noch besser einen Gast-Beitrag hier hinterlassen

• Ein absolutes Must-Have-Tool zum Entwickeln für den Internet Explorer ist die IE Developer Bar, welche ähnliche Features wie das Firefox-Addon Firebug im IE zur Verfügung stellt.
• Ein CSS-Reset erweist sich auch oft als sehr hilfreich, da dieser die unterschiedlichen Standard-Style-Definitionen der Browser auf einen einheitlichen Stand zurücksetzt.
• Conditional Comments helfen Stylesheets, JavaScripts und HTML-Code nur unter bestimmten Bedingungen ausführen zu lassen. Somit kann man einfach und schnell CSS-Definitionen, welche bspw. nur für den IE6 gelten sollen, erstellen.
• In jQuery ist die Browser-Detection einhilfreiches  Feature um Browser-Bugs zu erkennen und diese zu umgehen.
• Zu den weniger technischen Tipps zählen natürlich das Sammeln von Erfahrung. Nichts ist wertvoller als Erfahrung das gilt Besonders beim Entwickeln und Testen. Wer schon beim Schreiben des Codes weiß, dass der IE 6 bestimmte CSS-Definitionen gar nicht kennt oder falsch interpretiert, kann bereits zu diesem Zeitpunkt darauf reagieren und somit viel Zeit sparen.
• Außerdem sollte man oft und möglichst viel testen. Haha, wär hätte es gedacht!? Nein, ich meine es ernst: intensive Testing-Phasen sollten als Teil der Softwareentwicklung angesehen werden und in der Aufwandsabschätzung entsprechend berücksichtigt werden, um die nötige Zeit zu schaffen, diese Tests durchzuführen.
• Kommunikation ist das A und O in Projekten mit mehreren Mitarbeitern. Das kann jeder bestätigen, der mal ein Team-Projekt in den Sand gesetzt hat. Nicht selten liegt das an mangelnder Kommunikation zwischen den Beteilligten. Warum dies hier relevant ist, hatte ich ja bereits in Punkt 5 weiter oben angesprochen.
• Der Entwickler sollte unter keinen Umständen der einzige Tester bleiben. Kein Tester ist besser als jemand, der nicht selbst an dem Projekt mitentwickelt aber die Anforderungen des Kunden kennt. Der Entwickler selbst übersieht zu schnell Fehler und kann daher keine so gute Qualitätssicherung betreiben, wie jemand der nicht schon seit 2 Wochen die gleiche GUI vor der Nase hat.
• Fehler passieren. Jedem. Selbst den Besten. Man sollte keine Angst haben sich seinen Fehlern zu stellen, sondern sie als wichtigen Bestandteil der Arbeit ansehen. Denn nur aus Fehlern lernt man und erst so entsteht die Erfahrung, welche benötigt wird um nicht die gleichen Fehler immer wieder zu machen.

Wendet man diese Tipps und Tools an, kann man das Testen und Optimieren von webbasierten System für die verschiedenen Browser effizienter gestalten und somit viel Zeit und Nerven sparen.

Kennt ihr weitere Tipps oder Tools? Welche Erfahrungen habt ihr gemacht?

Ähnliche Artikel

• Quick’n'Dirty: Stylesheet Limits im IE
• [CSS] Firefox: Darstellungsprobleme bei contenteditable
• Der Internet Explorer 9 ist da