Sascha Postner macht Jagd auf Kommunikation, Webstandards und Public Relations

Trotz aller Unkenrufe entwickele ich auch derzeit fleißig an barrierefreien Webseiten. Und bei der Arbeit zu einem aktuellen Projekt bin ich auch mal wieder über einen Internet Explorer Bug gestoßen. Diesmal aber mit einer kleinen Besonderheit zu allem was mir vorher widerfahren ist: Dieser Bug scheint nur im IE7, nicht jedoch im IE6 aufzutreten.

Ich gebe zu, dass ich mir nicht die Mühe gemacht habe alles bis ins letzte Detail auszutesten, so kann es also sein, dass der DOCTYPE eine Rolle spielt oder, dass der Bug doch im Internet Explorer 6 existiert, aber mit bestimmten Einstellungen auf meinen Testrechnern unterdrückt wird. Wie auch immer hier isser.

Der Bug im IE7

Es sollte sich von selbst verstehen, aber natürlich kann man das Verhalten live nur im IE7 nachvollziehen . Was passiert?

Beim bewegen der Mouse über den Link springt er plötzlich nach links. Das liegt jedoch nicht an einer Auszeichnung in der Pseudoklasse :hover und ist einfach nicht gewollt. Ein Reload der Seite bringt den Link wieder an die richtige Position.

Schauen wir uns einmal an wie der HTML und der CSS Code aussieht:

CSS

a:hover { background-color: red;}
#center-content {
position: relative;
border:1px solid red; }

.lbContent {
border: 1px solid #CCC;
margin-left: 100px;
float:left; }

HTML

<div id="center-content">
<div class="lbContent"><a href="http://blog.postner.de/#">Hover this link</a></div>
<br style="clear: both" /></div>

Das Problem

Scheinbar verliert der DIV-Container mit der CSS-Klasse lbContent im Moment des Hovers den Margin-left von 100px.
Ich konnte den Bug relativ weit eingrenzen, denn es IST wichtig, dass der umrandende Container relative positioniert ist (was natürlich gelegentlich vorkommt, da man ja so darin enthaltene Objekte an ihm orientiert absolute positionieren kann) UND es scheint auch wichtig zu sein, dass der Container, der in diesem Beispiel hüpft floated.

Die Lösung

Wenn man alle Ratschläge der Gurus befolgt wird man vermutlich gar nicht auf diesen Fehler stoßen, denn er resultiert letztlich aus dem Link, dem beim hover eine andere background-color zugewiesen wird.
Wie schon erwähnt, ich habe nicht endlos getestet ob es auch mit anderen styles, anderen Verschachtelungen oder anderne Testumgebungen funktioniert, aber bei mir wurde das Problem in der Tat durch die Hintergrunfarbe des Links hervorgerufen.

Eine einfache Zuordnung einer Hintergrunfarbe auch für den “normalen” Link hat das Problem behoben (wie immer zu einfach um es für wahrscheinlich zu halten!).

a:link, a:visited, a:active { background-color: #fff;}

Das war es schon! Easy! Und da die Empfehlung eh heißt, wenn du eine Schriftfarbe bestimmst, bestimm auch eine Hintergrundfarbe sollte es für die meisten Leute keine Probleme geben.(Bitte beachtet, dass ich in den funktionierenden Beispielen auf dieser Seite einiges anders gebaut habe als ich es in den Codeschnipseln zeige, um es hier gut darstellen zu können, der Quelltext dieser Seite ist also unterirdisch und hier flackert sonst auch viel auf der Seite! ;))

Ich hoffe das hilft dem einen oder anderen. Vielleicht hat ja jemand Lust das ganze auch in Englisch zu übersetzten (und mir entweder den Text oder einen Link auf die Englische Erklärung zu senden). Oder ihr zeigt mir wo der Bug bereits seit Monaten beschrieben wird
Sollte es noch andere Nebeneffekte oder ähnliche Auswirkungen mit anderen Konfigurationen geben sagt mir Bescheid.

Sorry noch einmal für diese knappe Aufbereitung, mir fehlt die Zeit. Ich finde es einfach wichtig solche Dinge zu berichten, damit auch andere davon profitieren können.

Denkt dran: http://www.technikwuerze.de/

Popularity: 19% [?]

Verwandte Artikel

• Keine verwandten Artikel

Dieser Beitrag wurde vor am Mittwoch, 28. Februar 2007 um 21:33 Uhr veröffentlicht und unter Browserbugs gespeichert. Sie können Kommentare zu diesem Eintrag über den RSS-2.0-Feed verfolgen. Sie können einen Kommentar hinterlassen oder einen Trackback von Ihrer Website hierher setzen.