Flackern beim Seitenwechsel im MS IE – Nachtrag

In einem der letzten Blog-Beiträge ging es um das Flackern des MS IE beim Seitenwechsel. Dort hatte ich zwei Tricks aufgeführt, mit denen man ohne Serveränderungen in manchen Fällen – leider nicht immer – eine Verbesserung herbeiführen kann.

In diesem Beitrag möchte ich kurz auf die Behandlung von MS IE-Flackern bei der Integration von Hintergrundsbildern für die gesamte Webseite eingehen. Da gibt es eine Geschichte, die es sehr verständlich macht, warum viele Webseiten-Entwickler den MS IE verfluchen.

Also – wie lädt man typischerweise Hintergrundsbilder für die gesamte HTML-Seite? Im -Tag per css-Anweisung. Typischerweise haben dann viele Seiten einer Domain dasselbe Hintergrundsbild und einen im wesentlichen gleichen Aufbau – es ändern sich beim Seitenwechsel nur ganz bestimmte BEreiche der Seite. Dann will man natürlich, dass ein Seitenwechsel sanft vor sich geht und der Hintergrund nicht flackert. Das Hintergrundsbild und alle anderen unveränderten Seitenelemente sollen beim Seitenwechsel statisch angezeigt, nicht neu aufgebaut oder neu geladen werden. Wozu gibt es schließlich den Browser-Cache …

Leider wird man aber beim MS IE in Abhängigkeit von der MS IE-Version feststellen, dass es dort bei Seitenwechseln, bei denen sich das Hintergrundsbild und wesentliche Anteile der Webseite (Grundaufbau) nicht ändern, dennoch zu Flackern kommt. Der Hintergrund wird kurz weiß, das Bild wird neu geladen. Das passiert ggf. nicht immer aber, doch sehr häufig. Wenn man genauer forscht, wird man feststellen, dass das Flackern besonders häufig oder immer bei Seiten auftaucht, bei denen zusätzlich zu den Hintergrundsbildern Flash-Elementen oder Javascript-Anteile vorkommen.

Deshalb sind ggf. zwei Tricks zu kombinieren, um das Flackern weg zu bekommen:

Fall 1) Es wird kein Javascript in der Webseite benutzt

Dann hilft es, das Hintergrundsbild nochmals (also zusätzlich zum Hintergrund im <BODY>) in einem DIV zu laden, das man per z-Index unter den gesamten übrigen Inhalt der Webseite legt. Hierzu benötigt man natürlich einen übergeordneten DIV-Container, in dem man das DIV für das Hintergrundsbild und ein DIV für den gesamten übrigen Inhalt absolut positioniert und übereinander legt.

Fall 2) Es wird Javascript benutzt, z.B. um Flash-Objekte in die Seite zu integrieren

Wir verwenden z.B. SWFObject und entsprechendes Javascript, um Flash zu integrieren. Es hat mich viele Tests gekostet, bis ich herausfand, dass allein schon das Einfügen eines Tags

<script type=”text/javascript”></script>

(also ohne jeden Code !) oder gar eines Tags

<script language=”JavaScript” src=”script/swfobject2.js” type=”text/JavaScript”></script>

im Header der HTML-Datei bereits ein Flackern beim Seitenwechsel zwischen Seiten mit Hintergrundsbildern auslöst. Für den Bruchteil einer Sekunde wird der Hintergrund weiß, das Bild wird neu geladen. Selbst wenn in der HTML-Seite keinerlei Javascript-Code ausgeführt wird. Unglaublich nicht ? Noch unglaublicher ist aber der Trick, der beim MS IE hilft:

Man kopiere den gesamten Script-Kram, soweit es die Logik der Seite zulässt, an das Ende des HTML-Codes und zwar unmittelbar vor das Ende des abschließenden </BODY>-Tags. Das ist zwar ungewöhnlich, aber kein Browser meckert einen formalen Fehler an. Und siehe da, auf einmal hört auch im MS IE das Flackern auf.

Das läßt tief blicken, in welcher Weise die Javascript-Engine in den MS IE integriert ist – Entschuldigung bei MS ist das ja eh eine Extrawurscht und nix Normales (JSCRIPT).

Leider kann es in einigen Fällen so sein, dass Javascript-Code zwingend vor dem Laden der übrigen HTML-Elemente ausgeführt werden muss. Dafür habe ich auch keine echte Lösung parat. Aber in vielen Fällen hilft der beschriebene Trick.

Überflüssig anzumerken, dass man den ganzen Quatsch so nicht braucht , wenn
man Firefox benutzt. Gott sei Dank hat ja nun Firefox zumindest in Deutschland dem MS IE den Rang abgelaufen.

Reihenfolge relativ und absolut positionierter DIVs

Anne kam vor kurzem mit einem typischen Problem im Zusammenhang mit der Positionierung von relativ und absolut positionierten DIVs in einem Container-DIV.

Fast wie immer klappte alles im Firefox oder in Opera unter Linux (und Windows) – nur nicht im MS IE (7,8).

Worum ging es?

Das Container-DIV hatte nur die Aufgabe,  einen definierten Bereich innerhalb der Webseite vorzugeben und bei Bedarf Scrollbedarf zuzuschalten. Das DIV war in seiner Umgebung relativ positioniert.

Innerhalb des Containers hatte Anne eine Reihe aufeinanderfolgender, relativ positionierter  DIVs undefinierter Höhe.  Die Elemente der DIVs wurden durch Datenbankinhalte gefüllt. Insgesamt ergaben die relativ positionierten DIVs  einen Hintergrundsbereich innerhalb des Containers. Alle befanden sich in der gleichen Ebene, die durch eine z-Index festgelegt wurden.

Zusätzlich gab es ein weiteres DIV, das absolut positioniert wurde und für das ein höherer Wert im z-Index gewählt wurde. Dieses DIV sollte also immer vor den relativ positionierten DIVs angezeigt werden.

Also:

<div id=”container” …. >
 
<!– das absolut positionierte DIV –>
<div id=”abs” style=”position:absolute; …. z-index:10; “>
…..
</div>
 
<!– die relativ positionierten DIVs –>
<div id= “rel_1 ” style= “…; z_index:1; ” ….. > …. </div>
<div id= “rel_2 ” style= “…; z_index:1; ” ….. > ….  </div>
…..
…..
   
</div>

Im Firefox wurde das abslout positionierte DIV auch brav über allen anderen DIVs angezeigt; im MS IE7 dagegen nicht und im MS IE 8 nur, wenn der Seitenaufruf mit geänderten PHP-Parametern geschah. Ein reiner Seiten-Refresh führte immer zu einem Ausblenden des absolut positionierten DIVs.

Die Lösung 

Was hatte Anne falsch gemacht ? Aus meiner Sicht gar nichts. Außer, dass sie hätte davon ausgehen müssen, dass der MS IE ein wenig Hilfe benötigt:

Der MS IE kriegt die obige Reihenfolge nämlich nicht auf die Reihe – im wahrsten Sinne des Wortes !

Hätte Anne die Reihenfolge von vornherein wie folgt gewählt, wäre nichts passiert:

<div id=”container” …. >
 
<!– die relativ positionierten DIVs –>
<div id=”rel_1″ style=”…; z_index:1;” ….. > ….  </div>
<div id=”rel_2″ style=”…; z_index:1;” …..> ….  </div>
…..
…..
 
<!– das absolut positionierte DIV –>

<div id=”abs” style=”position:absolute; …. z-index:10; “>
…..
</div>
 
</div>
n
Merke:

Im MS IE ist es zwingen, die relativ positionierten DIVs vor den absolut definierten DIVs zu definieren. Sonst bekommt der MS IE den Ebenenaufbau nicht hin.

Arme Web-Designer ! Das ist kein Spass mit dem MS IE.

Flackern beim Seitenwechsel im MS IE

Viele Websites beinhalten Seiten, die vom Grundaufbau/Layout her völlig identisch aussehen. D.h., sie beinhalten viele begrenzende oder Hintergrunds-Elemente, die auf allen Seiten völlig gleich aussehen.

Bei einem Wechsel zwischen zwei Seiten erwartet man dann, dass die identisch aussehenden Seitenelemente während des Wechsel ohne jedes Flackern dargestellt werden. Der Wechsel soll für das Auge des Betrachters also so ablaufen, als ob nur die unterschiedlichen Seitenanteile im Wechsel neu aufgebaut werden. Die identisch aussehenden Elemente sollen beim Seitenwechsel dagegen als völlig statisch erscheinen. Es soll vor allem zu keinem Flackern beim Seitenaufbau kommen. Flackereffekte (kurzzeitige Hell-Dunkel-Wechsel in bestimmten Seitenbereichen) wirken auf die meisten Betrachter irritierend.

Leider stellt man aber immer wieder fest, dass es gerade bei komplexeren Seiten im MS IE zu diesem unangenehmen Flackern kommt – oft genau in den Bereichen, die beim Seitenwechsel eigentlich unverändert bleiben. Dagegen kann man bei Browsern wie Firefox, Opera, Konquerer oft  einen stabilen, flackerfreien Bildwechsel während des Renderns der neuen Seiten konstatieren. (Ausnahmen stellen Seiten dar, die Flash-Elemente beinhalten.) Wir haben das Problem schon des öfteren mit gewöhnlichen HTML-Seiten, aber auch im Zusammenhang mit PHP-Seiten festgestellt.

Wie kann man als Entwickler das nervige Flackern im MS IE in den Griff bekommen ?

Hierfür gibt es nach unserer Erfahrung mindestens zwei Tricks:

Trick 1: MS IE spezifisches Metatag

Im MS IE kann man den Seitenwechsel mit (teils spektakulären) Effekten unterlegen, die eine bestimmte Zeitdauer haben. Die Render-Engine arbeitet in diesem Modus anders als gewöhnlich. Wir nutzen das an dieser Stelle zur Vermeidung des Flackerns aus. Zur Parametrierung der Effekte dient ein Metatag der folgenden Form

<meta http-equiv=”Page-Enter” content=”revealtrans(duration=0.1,transition=5)” >

Der Parameter “duration” gibt die Zeitdauer des Effektes in Sekunden an, der Parameter “transition” den ausgewählten Effekt. In unserem Fall wird die Seite von oben nach unten aufgebaut (abgerollt) – die Zeitdauer ist allerdings so kurz gewählt, dass man das praktisch nicht merkt. Der von uns gewünschte Seiteneffekt ist allerdings der, dass ein Seitenwechsel nun in vielen Fällen völlig stabil und ohne jedes Flackern vor sich geht.

Weitere Information zu “revealtrans” findet man im Internet.

Trick 2: Einbau von Dummy-DIVs mit einer Opacity-Anweisung

Auch wenn man auf einem Layer der Webseite mit hohem z-Index ein Dummy-DIV mit einer Opacity-Vorgabe integriert, reagiert die Render-Engine des MS IE positiv im Sinne der Flackerfreiheit. Ein Element der Form :

<div style=”position:absolute; width:0.5em; height:0.5em; top:0.1em; left:0.1em; filter: alpha(opacity=66); -moz-opacity: .66; opacity: .66; z-index:10;”></div>

ist an sich zwar völlig sinnlos (da ohne Hintergrundsfarbe), zieht aber dennoch die Flackerfreiheit des Seitenaufbaus nach sich. (Ausschlaggebend für den MS IE ist dabei übrigens die “filter”-Anweisung.)

Viel Spass in Zukunft beim “Beruhigen” des MS IE.

Nachtrag am 18.11.2009: 

Im Falle von Hintergrundsbildern, die per CSS in Tags eingebunden werden, helfen die obigen Tricks in der Regel nichts. Siehe aber die Hinweise von Anne zu weiteren Möglichkeiten im Kommentar ! Danke, Anne !

Nachtrag am 28.11.2009

Anne hat mich darauf aufmerksam gemacht, dass beim MS IE in vielen Fällen auch der unauffällige Einbau eines kleinen Dummy-Flash-Films, der eigentlich nichts tut, zur Stabilisierung des Bildaufbaus und zur Vermeidung von Flackereffekten hilft. Wegen evtl. Schwierigkeiten mit Flash-Filmen in Gecko/Mozilla-Browsern ist das aber kein Trick, den man generalisieren könnte.

Interessant ist auch, dass im Moment das
gleichzeitige Öffnen mehrer Tabs mit Webseiten, die per SWFObjects 2.x eingebaute Flashfilme beinhalten, im Firefox zu Flackereffekten beim Seitenwechsel führt – zumindest unter Linux.  Es ist ein Leiden !

Ferner hat mich Anne mit einigen Beispielen, bei denen im BODY-Tag Hintergrundsbilder per CSS verankert wurden, davon überzeugt, dass es im MS IE (alle Versionen) manchmal sogar von Nachteil sein kann, den “revealtrans”-Effekt einzusetzen. Besser ist es da anscheinend, das Bild, das man im Body-Tag untergebracht hat, nochmal in Form eines gewöhnlichen IMG-Tags in einem DIV zu hinterlegen, das man per z-index unter allen anderen Seitenelementen einfügt.

OK, OK, ich gebe auf – es gibt keine Standardrezepte – man muss halt herumexperimentieren.

Wenn man Zeit hätte, könnte man ja die Sache mal systematisch untersuchen – Seitenwechsel bei vorhandenen Hintergrundsbildern, beim Vorhandensein  von Flash und das in allen gängigen Browsern unter Linux und  MS Windows.  Ach ja, man müßte dann auch noch die unterschiedlichen Arten der Einbindung von Flashfilmen berücksichtigen …..

Zweites Alpha-Release 64 Bit Flashplayer

Ich habe heute das zweite alpha-Release des 64Bit-Flash-Plugins von Adobe für Linux ausprobiert.

Der größte Fortschritt ist für mich war, dass dieses Plugin nun auch mit Konqueror KDE 4.2 funktioniert !

Ich habe meinen ursprünglichen Beitrag

https://linux-blog.anracom.com/2009/01/26/kurztest-der-64-bit-version-des-flash-plugins-von-adobe/

zum ersten Release abgeändert und so aktualisiert, dass die Installation auch mit dem neuen Release funktioniert.

Getestet habe ich unter aktuellen Versionen von Konqueror, Firefox und Opera (alles 64 Bit unter Opensuse 11.1 mit KDE 4.2 (Factory Repository)). Sieht ganz gut aus !

Weiter so Adobe ! Endlich habt ihr begriffen, dass Innovation über Linux und nicht über Micro-Software läuft ! Dann macht es ja vielleicht in naher Zukunft sogar wieder Spaß, Flash-Applikationen zu entwickeln!

KDE 4.2, Firefox, Checkboxen und Radiobuttons

Ein paar Bekannte haben beim Einsatz von Firefox unter KDE 4.2 das gleiche Problem mit Web-Formularen, das auch ich nach dem Umstieg auf KDE 4 hatte:

Die Checkboxen und Radiobuttons funktionieren optisch im Firefox 3 nicht richtig – zumindest nicht auf einer Default-Opensuse-11.1-Installation, die um KDE 4.2 ergänzt wurde. Man kann Checkboxen z.B. zwar anklicken – danach sieht man aber keinen Haken. Dieser taucht erst wieder auf, wenn man im Formular an anderer Stelle mit der Maus klickt. Ziemlich irritierend, weil man nicht direkt sieht, ob eine Checkbox/Radiobutton nun aktiv ist oder nicht.

Das ist aber kein Firefox-Problem, wie man meinen könnte, sondern ein GTK-Thema. In etlichen Kubuntu-Blogs wird zum gleichen Thema empfohlen, einen vernünftigen GTK-Style über die KDE 4 “Systemeinstellung” zu wählen. Das reicht nach meiner Erfahrung unter Opensuse leider nicht – man benötigt nämlich noch ein paar notwendige Bibliotheken, die nicht in ihrer Gesamtheit installiert sind.

Essentiell bei SUSE sind grundsätzlich die Pakete gtk und gtk-qt-engine – letzteres für KDE. Das korrekte Anzeigen der Checkboxen hängt aber an zusätzlich benötigten GTK2 Bibliotheken. Man benötigt deshalb auch die Pakete “gtk2”, “gtk2-engines”, “gtkhtml2”, “libgtkhtml”, “qtcurve-gtk2”, “qtcurve-kde4” und ggf. für die Einstellung von GTK-Themen “gtk2-themes”, “kde4-kcm_gtk”.

Als GTK-Theme oder Stil habe ich über das KDE 4.2-Konfigurationszentrum
“Systemeinstellungen (system-settings)-> Erscheinungsbild->GTK-Stile und Schriftarten”
übrigens “QtCurve” gewählt. Das ist auch eine notwendige Bedingung für das Beseitigen der Probleme mit den Checkboxen!

Ferner habe ich “KDE-Schriftarten in GTK-Anwendungen verwenden” aktiviert. Das zwar für das Checkboxen-Thema unerheblich, trägt aber zu einem besseren Aussehen bei.

Danach sieht der Firefox ganz ordentlich aus und die Checkboxen in Formularen funktionieren anstandslos.

P.S.: Liste an GTK-relevanten Paketen
Der Vollständigkeit halber hier eine vollständigere Liste von gtk-relevanten Paketen, die bei mir (aus verschiedenen Gründen u.a. Entwickung) auf einer Workstation installiert sind:
glib, gtk, gtk-32bit, gtk2, gtk2-32bit, gtk2-branding-openSUSE, gtk2-devel, gtk2-engines, gtk2-engines-32bit, gtk2-lang, gtk2-theme-openSUSE, gtk2-themes, gtkglext, gtkglext-32bit, gtkhtml2, gtkhtml2-devel, gtkhtml2-lang, gtkmm2, gtkmm2-devel, gtk-qt-engine, gtk-gt-engine-32bit, gtk-sharp2, gtk-sharp2-32bit, gtk-sharp2-32bit, gtksourceview18, gtkspell, gtkstyle, gxine, kde4-kcm_gtk, libgtkhtml, libgtkhtml-32bit, libgtkimageview0, libsexy, libwebkit-1_0-1, perl-Gtk2, phat, python-gtk, python-qt, qtc, qtcurve-gtk2, qtcurve-gtk2-32bit, qtcurve-kde4

———————————————————

Eigene Ergänzung II vom 22.02.2009:
*********
Muss mich nochmal entschuldigen für die Verwirrung, die ich mir selber und evtl. anderen heute durch meine erste heutige Ergänzung (s.u.) bereitet habe. Nach ein wenig Nachdenken und weiteren Checks lässt sich das Checkbox-Problem von Firefox 3.0.6 unter KDE 4.2 (Factory-Repository von Opensuse 11.1) doch beheben:

1) Ich habe bei den letzten Updates einen Fehler begangen und das Paket “qtcurve-kde4” leider aus dem Unstable-Zweig und nicht aus dem Factory-Zweig installiert. Das war eine der Ursachen dafür, dass die oben vorgeschlagene Problemlösung zwischenzeitlich nicht lief (s. meinen Einschub unten). Mit der aktuellen Version von KDE 4.2 aus dem SUSE Factory-Repository und der zugehörigen Version 0.60-2.2 von “qtcurve-kde4” ist alles wieder OK.

2) Ich habe zu meiner Schande zudem vergessen, das Paket “qtcurve-kde4” in den Listen der erforderlichen Pakete oben mit einzufügen. Ohne dieses Paket geht aber gar nichts. Diesen Fehler habe ich nun korrigiert und das Paket oben in fetter Schrift
hervorgehoben.

Ich hoffe, dass ihr das Problem nun unter Berücksichtigung der übrigen Hinweise des originalen Beitrags in den Griff bekommt ! Sorry nochmal – ich hätte gleich sorgfältiger arbeiten müssen.

[
Inzwischen irrelevante Ergänzung I vom 22.02.2009:
*********
Sorry, liebe Leute:
Der obige Artikel zur Lösung des Checkbox-Problems in Firefox stimmt leider nicht mehr. Nach einer weiteren Update Runde mit Firefox (3.0.6) und KDE 4.2 aus dem Factory Repository von SuSE ist das Problem mit den Checkboxen und Radiobuttons von Firefox wieder da – auch wenn man die oben empfohlenen Bibliotheken installiert hat und QtCurve als GTK-Scheme eingestellt hat.
]