IE8, HTML5 und Fancybox

Tja, der liebe IE8 kann halt auch nicht mit HTML5, wenn man Fancybox verwenden möchte. Das kann jetzt natürlich auch am modernizr liegen, dass eben Inhalte, die per Ajax nachgeladen werden, nicht mehr für die alten IE Versionen modifiziert werden.

Ich werde wohl mal mit innerShiv beschäftigen, vielleicht läuft es dann ja wie gewünscht. So lange aber werde ich nachladbare Inhalte lieber noch ohne HTML5 Elemente erstellen.

Wenn ich dann noch einen Wunsch frei hätte, würde ich mir wünschen, dass Microsoft dem Internet Explorer die gleiche Silent Update Routine Ihrem Produkt hinzufügt, wie Sie Google schon seit langem für Chrome verwendet. Bedenken ob des Zugriffs auf den Anwenderrechner hin oder her, aber so könnte man gewährleisten, dass alte IE Versionen endlich mal nahezu aussterben würden.

*Update*
innerShiv funktioniert auch mit via Fancybox und Ajax nachgeladenen Inhalten scheinbar einwandfrei. Das hat mir jetzt eine menge Arbeit beim umschreiben von HTML5 zurück zu HTML4.01 oder XHTML1.0 erspart.

IE7,8 Bug mit Problem aus iFrames

Ab und an muss man noch mit iFrames arbeiten, vor allem, wenn man eigene Inhalte auf Facebook Fanseiten zu Verfügung stellen möchte. Mitunter möchte man auch schon mal Daten persistent von einem Tab zum Nächsten beim User speichern, z.B. für eine Sprach- oder Ländereinstellungen. Klar denkt man dann sofort an Cookies.

Wenn man, wie ich, überwiegend mit Chrome oder Firefox testet und den Internet Explorer nur am Schluss zur Überprüfung des Layouts, mit all seinen Tücken, für die letzte Qualitätssicherung hinzu zieht, kann man gerade bei Cookies, die in einem iFrame gesetzt werden, eine Überraschung erleben. Obwohl die Standard-Sicherheitseinstellungen das Speichern des Cookies zulassen müssten, entdeckt man plötzlich ein kleines Warnsymbol in der Statusleiste des IE, mit dem Hinweis, dass der Cookie geblockt wurde. Zuerst dachte ich dann, wird der Cookie in den anderen Browser etwa auch geblockt, aber das kann ja nicht sein, da dort alles einwandfrei funktionierte.

Jedenfalls gibt es beim W3C ein Projekt Namens Platform for Privacy Preferences (P3P). Und dieser quasi Standard des W3C sorgt unter anderem dafür, dass Cookies im IE7 und IE8 nicht wie erwartet funktionieren.

In einem Blog-Eintrag von Adam Young habe ich dann die Lösung (PHP) für das Problem gefunden: http://adamyoung.net/IE-Blocking-iFrame-Cookies

Siehe da, nun klappt es auch im IE.

Facebook, iFrames, HTML5 und der liebe IE

Bei dem aktuellen Projekt, welches eine Implementierung einer Facebook App war, gab es allerhand Hürden zu nehmen. Zum einen finde ich die Dokumentation der Facebook API stellenweise immer noch dürftig, zum Anderen ändert Sie sich auch relativ häufig, was manch Hilfestellungen, die man per Google findet, schon wieder veraltet sind, selbst, wenn sie aus dem Jahr 2010 stammen.

Nachdem ich mich auf diversen Seiten eingelesen habe konnte ich schließlich die kleine Bewerbungsseite für unseren Kunden als App auf Facebook erstellen. Seitdem Tabs auf Facebook-Fanseiten und Apps prinzipiell als iFrame realisiert werden und dort eigentlich zumindest Serverseitig nahezu alles möglich ist, was auch auf einer eigenen Seite umgesetzt werden kann, faktisch läuft es ja in einer eigenen Umgebung, ist es um einiges einfacher geworden. Vor ca. 2 Jahren, bei meinem ersten Versuch, mich mit dem Thema auseinander zu setzen, fand ich mehr Probleme und vor allem Einschränkungen vor.

Jedenfalls kam ich auf die Idee, als Grundgerüst für die View auf HTML5 zu setzen, dank Boilerplate ist das ja kein großes Problem mehr, wenn es um die Crossbrowser-Kompatibilität geht. Na ja, nach kurzer Zeit sah das ganze ja auch gut aus, dachte ich. In den bevorzugten Browsern (Chrome und Firefox) sah das ganze wie gewünscht aus, aber der Internet Explorer in Versionen kleiner als 9 spielte nicht mit. Haben der IE7 und der IE8 eigentlich mit nativen HTML5 Seiten danke Boilerplate keine Probleme (siehe www.nissan-in-berlin.de), stellte sich bei der Facebook-App heraus, dass hier die HTML5 Elemente im verwendeten iFrame nicht mehr interpretiert wurden. Der IE9 zeigte dieses Verhalten nicht. Letzten Endes musste ich alle section, article, aside (und viele mehr) Elemente wieder entfernen und durch Divs mit aussagekräftigen IDs versehen.

NISSAN Fame by Frame APP

eine von mehreren Bewerbungsseiten der Fame by Frame Aktiob

Merke: Bei Facebook Applikations lieber noch auf XHTML1.0 oder HTML4.01 setzen.