Google-Chrome 10: CSS Adjacent-Selector-Bug gehackt

Samstag, 16 April 2011 16:48 MET

Thema:
Webgestaltung  
Stichworte:
, , ,  
 
Verärgerte Frau hält Schild mit Chrome-Logo
Google-Chrome 10: CSS Adjacent-Selector-Bug gehackt [hyperkontext | Weblog]

Die simple CSS-Anweisung h2+p {font-weight:bold} kann mit Chrome10 ein optisches Desaster hinterlassen. Mit Chrome11 sollte der Spuk wieder vorüber sein. Für dringende Fälle habe ich einen Hack entdeckt.

In Kombination mit :hover wird die Sache komplizierter, weil sie augenscheinlich mit einem älteren Webkit-Bug zusammenhängt, der auch Safari betrifft. Nach einigem Rumprobieren ergab sich eine Art Rundum-Hack.

Kommentare zu meinem Herumgehacke wären hilfreich.

Update 2011-04-28:
Seit der heutigen finalen Version 11 – die sich normalerweise automatisch installiert – scheint der beschriebene Bug gefixt zu sein. Dieser Beitrag ist somit weitgehend obsolet.

Schlimmer als mit IE

Seit Google-Chrome Version 10 eröffnet sich ein Bug, den wir normalerweise nur unterbelichteten IEs zuschreiben würden. In Chrome9 trat das Problem definitiv noch nicht auf.

Die simple CSS-Anweisung h2+p {font-weight:bold} kann mit Chrome10 ein optisches Desaster hinterlassen. Statt immer den ersten Absatz nach einer Überschrift zweiter Ordnung fett auszuzeichnen, werden flugs einfach alle Absätze nach den Überschriften fett. Schlimmer also als mit IEs bis Version 7, welche die gesamte Anweisung nicht verstehen und somit ignorieren.

Das Malheur offeriert sich aber in unterschied­licher Ausprägung.

Kommt hinter dem Adjacent-Selector zum Beispiel die Pseudoklasse first-letter zum Einsatz, also zum Beispiel h2+p:first-letter {font-size:200%}, dann wird nur der erste auftretende Fall korrekt angezeigt – also der erste Buchstabe des ersten Absatzes hinter der ersten Überschrift vergrößert – und alle weiteren ignoriert. Eher nur eine optische Bagatelle, die ich auch auf diesem Blog nicht gefixt habe.

Werden beide genannten Beispiele jedoch kombiniert, zeigt Chrome10 alles wie gewünscht an. Etwas veränderte Kombinationen – wie auf der Demoseite gezeigt – bringen wieder unvorhersehbare Ergebnisse. Getestet mit Version 10.0.648.205.

Wie dem auch sei, der Bug kann in bestimmten Konstellationen verheerende Folgen haben. Der Trost ist, dass er angeblich mit Chrome11 wieder verschwunden ist. Realistisch ist somit, dass dieser Spuk in wenigen Wochen vorüber sein wird.

Für dringende Fälle habe ich einen Hack entdeckt: Mit dieser einfachen Anweisung zu Beginn der CSS-Datei, scheinen die Falschinterpretationen in Chrome10 mit dem Adjacent-Selector zu verschwinden:
* {-webkit-animation-name: SelectorFix;} – wobei der Name irgendeiner sein kann.

> Demoseite zum Chrome10 Adjacent-Selector-Bug, mit und ohne Hack. Sinnvoll natürlich nur mit Chrome zu testen.

Aber Vorsicht! Wenn zusätzlich die Pseudoklasse :hover ins Spiel kommt, dann wird es leider komplizierter und betrifft auch den Safari:

Mit :hover wird es komplizierter

Augenscheinlich hängt der eben geschilderte Fehler mit einem älteren Bug – in Kombination mit der Pseudoklasse :hover – zusammen, der Webkit betrifft und daher sowohl die Browser Chrome, als auch Safari. Da dieser Bug schon länger bekannt ist und noch immer nicht gefixt wurde, scheint es so, dass dieses Problem auch nicht mit Chrome11 oder einer neueren Safari-Version mit Sicherheit beseitigt wird.

In diesen Beiträgen wird die Sache genauer beschrieben:

Die dort beschriebenen Hacks funzen zwar in den jeweiligen Fällen, nicht jedoch für die eingangs erwähnten neuerdings auftretenden Probleme in Chrome10.

Wie ich weiters feststellte, treten Probleme manchmal auch gar nicht auf, wenn irgendwo in der CSS-Datei ein ~ Selektor verwendet wird, der sich auf diejenigen Elemente bezieht, die später mit + angesprochen werden. Wie wir also sehen, scheinen diese fehlerhaften CSS-Interpretationen in komplexerem Zusammenhang zu stehen.

Von Betriebssystemen scheinen die Probleme unabhängig zu sein, da sich die Bugmeldungen, die großteils von Apple-Systemen stammen, für Windows ebenso nachvollziehen lassen.

Mein Rundum-Hack

Die gute Nachricht: Nach einigem Rumprobieren ergab sich eine Art Rundum-Hack, der diese Malversationen zusammen mit der eingangs erwähnten fixt:

* {-webkit-animation: SelectorFix infinite 1s;}
@-webkit-keyframes SelectorFix {
from{zoom:1;}to{zoom:1;}
}

Es ist eine Kombination aus den bekannten Hacks, mit dem anfangs erwähnten einzeiligen von mir. Der entscheidende Punkt scheint zu sein, in der ersten Zeile das Universalsternchen zu setzen und nicht body oder html.

Da ich aber ehrlich gesagt nicht der große Hack-Guru bin und die Tiefen der Anweisung @-webkit-keyframes nicht eingehend studierte und daher auch nicht in all seinen Wirkungen verstehe, kann ich auch nicht sagen, ob der gezeigte Hack theoretisch logisch passt. Ich probierte zumindest viele CSS-Kombinationen durch und die zwei Zeilen scheinen die neueren Probleme mit Chrome10 in Kombination mit dem älteren Bug, der auch Safari betrifft, zu fixen.

Gegenteilige oder bestätigende Kommentare zu meinem Herumgehacke wären daher hilfreich.

Abschnitt 1 von 1

Update 2011-04-28:
Seit der heutigen finalen Version 11 – die sich normalerweise automatisch installiert – scheint der beschriebene Bug gefixt zu sein. Dieser Beitrag ist somit weitgehend obsolet.

Weitere Verweise:

Externe Verweise dieses Artikels wurden zuletzt am 16. April 2011 auf Relevanz geprüft.

Datum:
veröffentlicht am 16 April 2011, 16:48 MET.
Artikel:
Google-Chrome 10: CSS Adjacent-Selector-Bug gehackt [hyperkontext | Weblog]
Kurz-URL:
http://hyperkontext.at/s/308
Thema:
Webgestaltung 
Stichworte:
, , ,  

Dieser Eintrag kann nicht mehr kommentiert werden.

Mögliche themenverwandte Artikel aus dem Weblog

Blättern (chronologisch)

älterer Artikel »
März 2011 im Kontext