Keine IE CSS HACKs mehr

Irgendwann ist es soweit, man muss sich nur noch mit IE Optimierungen beschäftigen und fängt an die speziellen Browser Hacks anzuwenden. Im Endeffekt erhält man am Ende schwer durchschau- und pflegbares CSS und da manche Browserhacks über verschiedene Browser Versionen gültig sind oder der IE8 einem Nutzer vorschlägt in den Kompatibilitätsmodus zu wechseln, ist das alles unoptimal. Abgesehen von der fehlenden Möglichkeit valides CSS zu erstellen.

Die Alternative mittels Conditional Comments CSS Dateien einzubinden finde ich persönlich auch unoptimal, einerseits finde ich den zweiten GET Aufruf für die extra CSS Datei überflüssig und anderseits finde ich es besser innerhalb einer CSS alles zu stylen und wenn möglich auf die Ausnahmen einzugehen.

weiterlesen

Die Internet Explorer Familie ist nicht immer so schlecht

Es ist nicht der 1. April und tatsächlich meine ich die Überschrift ernst.

Kürzlich musste ich viele vermeindliche IE-Familien-Fehler beheben und im Endeffekt feststellen, das der Fehler im MarkUp oder Javascript lag. Da hat die Sturheit der verschiedenen IE-Versionen besseres HTML und Javascript zur Folge gehabt. Hier ein paar Beispiele:

Fall 1: In allen IEs (6-8) wurden Bilder nicht angezeigt? Das ausgespielte HTML wurde aus einem Blog RSS Feed gebildet und Chrome/Safari/Firefox zeigten alles richtig an. Nur alle IEs nicht. Ein Blick in den Quelltext zeigte das die Bilder als Höhenangabe „yy“ und Breitenangabe „xx“ hatten. Also hatte die IE Familie einen Fehler des Blog aufgedeckt.

Fall 2: Ein Javascript funktioniert nicht wie gedacht im IE6 und 7. Im Markup hatte ich eine Liste <ul> und jedes seiner <li>s beherbergte einen Link mit der Klasse „epaper„. Im jQuery wurde mittels $('a.epaper').fancybox(…) ein Verhalten festgelegt. Nun funktionierte dies in allen anderen Browsern, nur IE 6 und IE 7 zeigten lediglich beim ersten <li> Element den gewünschten Effekt ?!
Als erstes habe ich natürlich den Quelltext der einzelnen <li>s Zeichen für Zeichen überprüft aber keine Veränderung festgestellt – die Liste wurde aus einem Template generiert. Danach musste eine Internetsuche nach „fancybox ie bug“ weiterhelfen, aber auch dort wurde ich nicht fündig, die aktuellste Fancybox Version wurde schon genutzt.
Als nächstes: Javascript $('a.epaper') Eventhandler auskommentieren, testen und sehen: Das Verhalten ändert sich nicht!? Weitersuchen im Javascript und folgende Eventhandler Definition finden: $('a#inline').fancybox(…)… Auch diese auskommentieren und endlich: In allen Browsern geht nichts mehr.
Nochmal den Quelltext zu rate ziehen und sehen das alle <a> Elemente in den <li> als id „inline“ bekommen. Das ist nicht valides HTML und IE6 und IE7 halten sich daran das eine id unique sein soll und hören beim setzten von Eventhandler per ID auf sobald sie die gesuchte id gefunden haben.

Zum Glück war der Eventhandler von $('a.epaper').fancybox(…);“ falsch gesetzt und hat dieses Quelltextmanko aufgebracht.

Diese Sturheit der IE Familie hat mich doch beeindruckt, da man hier weniger fehlertolerant zur Sache geht und dadurch das Webmeistern wieder in eine professionellere Ecke stellt. Das hat mir gefallen.

IE feature: nicht $(‚ie[text=xyz] && $(‚ie‘).text(), sondern $(‚ie‘).html()

Ich hatte mir einen so schönen jQuery Ausdruck zusammengebaut und dann kam der Internet Explorer dazwischen :(

Generell wanderte ich durch ein paar <li>-Objekte und wollte eins von ihnen mit der Klasse aktiv hervorheben.
$(o).find('li[text=3]').addClass('aktiv');
fertig! (Firefox und Chrome Entwickler brauchen nicht mehr weiterlesen)

In jedem IE greift diese Formel aber nicht.

weiterlesen