Lösung: Das JavaScript in eine eigene Datei auslagern (z. B. mit dem Namen stop-hover-bug-ie6.js) und dann im Quellcode mit Conditional-Statements (heißen die so?) die Datei nur laden, wenn es der IE6 ist:

Gruß,
Thomas

Bei einigen der häufig vorkommenden Fälle wie “Website-Logo mit Image-Replacement ist gleichzeitig Link zur Startseite” kann man ja noch etwas über die Bildgröße etc. “retten”, bei einer klassischen Listen-Navigation mit “Pfeil am Menüpunkt” o.ä. kommt man allerdings in der Regel kaum ohne Positions-Angaben für das Hintergrundbild aus oder Werte für Background-Repeat aus.

Aber nun wird dies JavaScript doch nicht als Gestaltungs- oder essentiell notwendiges Bedienungs-Element eingesetzt und sperrt von daher keine Besucher aus. Außerdem hab ich noch nicht beobachtet, dass ältere Browser dadurch abstürzen (wie beispielsweise der Netscape 6 beim Google-Analytics-Code) - Für die Fälle, in denen man auch durch “Zusatz-Spans” oder irgendwelche “Umformulierungen” des Quellcodes das Flackern nicht vermeiden kann, sollte man das Script doch eigentlich auch auf Seiten einsetzen “dürfen”, in denen JavaScript sonst “unerwünscht” ist …?

Mit einem kompletten “Verbot” von JavaScript hatte ich zumindest bislang noch nicht zu tun. Und … jedenfalls nach meinen Besucherstatistiken ist der Anteil von Besuchern ohne JavaScript ziemlich gering und der Anteil von IE6-Nutzern ohne JS quasi gleich Null …

@pufaxx: Bezüglich der Arbeit mit CMS und ähnlichem muss ich dir recht geben. Ist leider blöd und man kommt um etwas Bastelei nicht drum rum, wenn man kein JavaScript verwenden will oder darf.

Wir dürfen bei einigen Projekten für unsere Kunden kein JavaScript nutzen und da kommt man dann nicht um solche Konstrukte wie das auf meiner Seite (von IaN verlinkt) beschriebene leider nicht drum rum. Oder halt in manchen Fällen noch schlimmer mit Spans in den List-Items.

Komplett ignorieren ist definitv keine Lösung, denn der IE6 ist einfach zu weit in den Firmen als Standardbrowser verbreitet und je nach Internetanbindung sieht so eine Seite echt unbenutzbar aus, weil z.B. das halbe Menü fehlt (weil es vom IE noch nicht nachgeladen wurde).

Was ich an der ganzen Sache nicht verstehe ist warum MS bei einem derartigen Bug nicht ein Bugfix raus bringt. Denn dieser Fehler tritt weder bei IE5.5 auf, noch beim 7.0.

Und in den Fällen war ich mit dem Ergebnis auch so weit zufrieden. Nur …

Manchmal hat man einfach keine Möglichkeit, dem umschließenden Element mit einem Hintergrundbild die passende Gestaltung zu geben (Beispielsweise weil das umschließende Element schon ein HG-Bild hat - oder weil man den Link irgendwie “relativ” verschieben muss, um irgendwelche Browser-Unterschiede auszugleichen). In solchen Fällen müsste man dann zusätzliche spans o.ä. einbauen. Ist nur etwas umständlich, wenn die Links von einem CMS erzeugt werden - und man dann die Ausgabe-Funktion umprogrammieren muss.

Gar keine andere Möglichkeit als JavaScript oder die Server-Lösung sehe ich bei einigen “Image Replacement”-Geschichten. Denn da bevorzuge ich die Methode, dass sich das Bild über den zu ersetzenden Text drüberlegt, damit man etwas lesen kann, wenn das “Ersatz”-Bild noch nicht geladen ist (die ganzen Unsichtbar-Mach-Methoden gefallen mir nämlich nicht) … Und Ersatzbild über den kompletten Link legen ist auch nix - denn dann kann man den Link nicht mehr anklicken. Es flackert außerdem nicht nur, wenn man einen Hover-Effekt haben will - es flackert ja auch, wenn es gar nicht hovern soll. Das ist ja der Ärger an der ganzen Geschichte.

http://www.eye-cu.de/wp/2006/11/24/css-flacker-bug-bei-ie6/