IE9 vs @font-face in S9y

[yellowled]

Mal im seperaten Thread, um zu entwirren: Wie nebenan im IE9-Thread schon angedeutet, stoße ich auf ein lustiges Problem mit IE9 und @font-face. Ich habe die Vermutung, dass es ähnlich gelagert ist und mit den HTTP-Headern (von denen ich leider wenig bis keine Ahnung habe) zusammenhängt.

Testcase in plain html: http://yellowled.dyndns.org/~matthias/t ... -demo.html

Testcase in S9y: http://yellowled.dyndns.org/s9y/

Hinweis: Beide Testcases liegen auf meinem lokalen Apachen, sind also nur zu erreichen, wenn mein Rechner läuft (lies: nicht 24/7).

plain html funktioniert überall - FF 3.6.x, Opera, Chrome, Safari und IE7-9. Der S9y-Case funktioniert auch überall, außer im IE9. Dort hängt sich der Browser auf, während er sich zu Tode lädt. Beide Cases nutzen dieselbe @font-face-Syntax und dieselben Webfonts-Dateien, allerdings eine andere HTML-Umgebung -- plain html ist in XHTML, S9y in HTML5 mit ein paar JS-Extras, die aber nicht stören dürften, zumal ich 1:1 dasselbe HTML5-Gerüst auf http://netzgestaltung.net verwende, wo es problemlos im IE9 funktioniert.

Jeglicher Hinweis würde mir weiterhelfen, evtl. Testergebnisse (Header-Anfrage etc.) liefere ich gerne nach, wenn man mir erklärt, was ich genau anliefern soll.

YL

[Timbalu]

in Ermangelung eines IE9 (GottseiDank )

Code: Select all

http://yellowled.dyndns.org/s9y/serendipity.css?v=0.1

GET /s9y/serendipity.css?v=0.1 HTTP/1.1
Host: yellowled.dyndns.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15
Accept: text/css,*/*;q=0.1
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Referer: http://yellowled.dyndns.org/s9y/
Cookie: s9y_blahblah
DNT: 1
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 200 OK
Date: Fri, 18 Mar 2011 17:53:05 GMT
Server: Apache/2.2.16 (Ubuntu)
X-Powered-By: PHP/5.3.3-1ubuntu9.3
Status: 200 OK
Expires: Fri, 18 Mar 2011 18:53:06 GMT
X-Blog: Serendipity
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 6165
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/css; charset=UTF-8

komisch das hier auch die Wildcard auftaucht, oder ist das ein Standard?
Accept: text/css,*/*;q=0.1

Hast du mod_negotiation aktiviert oder besteht das Problem unabhängig davon?

[yellowled]

in Ermangelung eines IE9 (GottseiDank )

Du, der ist ansonsten wirklich nicht schlecht. Als ich das S9y InfoCamp zum ersten Mal mit box-shadow, HTML5-Audioplayer etc. im IE sah, hab ich ein bißchen geweint.

Hast du mod_negotiation aktiviert oder besteht das Problem unabhängig davon?

Argh. Tatsächlich ist (unbewusst) auf meinem lokalen Apachen mod_negotiation enabled. Okay, jetzt muss ich erstmal rausfinden, wie man das abklemmt.

YL

[yellowled]

Tatsächlich ist (unbewusst) auf meinem lokalen Apachen mod_negotiation enabled. Okay, jetzt muss ich erstmal rausfinden, wie man das abklemmt.

Abgeklemmt, neu geladen, Problem besteht immer noch.

Zusätzlicher Testcase, der mein S9y-Gerüst in HTML abbildet: http://yellowled.dyndns.org/~matthias/test2/ (funktioniert in IE9)

YL

[Timbalu]

Tatsächlich ist auf meinem lokalen Apachen mod_negotiation enabled.

Ist das derselbe lokale Testserver gewesen, mit dem das ursprüngliche css Problem, im Vergleich mit dem Apachen von all-incl, im IE9 nicht auftrat? Das wirft dann doch noch mal ein anderes Licht..... (siehe Garvins und meinen Zwischenaustausch auf Seite 4) auf die eventuelle Lösung.

[yellowled]

Tatsächlich ist auf meinem lokalen Apachen mod_negotiation enabled.

Ist das derselbe lokale Testserver gewesen, mit dem das ursprüngliche css Problem, im Vergleich mit dem Apachen von all-incl, im IE9 nicht auftrat? Das wirft dann doch noch mal ein anderes Licht.....

Ein klares „Jein“. Ja, es ist derselbe lokale Testserver. Nein, mein Webhoster ist sich ziemlich sicher, dass es an mod_negotiation liegt. Nein, ich kann nicht ausschließen, dass die font-face-Geschichte eine ganz andere Ursache hat.

Mal ganz systematisch:

1. Es kann nicht am Rest vom Template liegen, denn http://yellowled.de funktioniert ja derzeit ohne Webfonts im IE9. Bestenfalls eine Wechselwirkung ist denkbar, etwa mit JS-Komponenten des Templates.

2. Es könnte an mod_negotiation liegen, allerdings hatte ich auf yellowled.de schon den Multi-Views-Fix und jetzt den Symlink-Fix, den mein Hoster empfiehlt (siehe anderer Thread) -- seitdem der aktiv ist habe ich es allerdings dort noch nicht getestet, auf dem localhost habe ich bislang nur MultiViews. Vor allem aber habe ich mod_negotiation ja mittlerweile lokal deaktiviert. Hm.

3. Es kann nicht an der Webfonts-Syntax oder den Fontdateien liegen, die funktionieren ja in diversen plain html-Testcases, zudem hat diese Syntax schon das halbe Web getestet. Fontspring ist keine Hinterhofklitsche. Diese Test waren zwar mit einem RC des IE9, aber wenn es im finalen IE9 nicht klappen würde, hätte ich das irgendwie mitbekommen.

4. Es kann auch nicht an {TEMPLATE_PATH} liegen, wie ursprünglich vermutet, denn a) klappt es z.B. auf http://s9ycamp.info und b) habe ich schon andere Pfadangaben getestet -- ohne Änderung im IE9.

Strange. Muss mehr testen. (Habe aber keine Lust. )

YL

[Freudi]

Was mir von außen aufällt ist, dass http://yellowled.dyndns.org/s9y/ anscheinend nicht validiert - im Gegensatz zu Deinem Strukturtest. Anyway, das scheint es nicht zu sein.

Deaktiviere ich im IE9 aber ActiveScripting, wird http://yellowled.dyndns.org/s9y/ sauber dargestellt. Also gefällt dem IE9 wohl "irgend etwas" an/in dem verwendeten JavaScript nicht. http://blogs.msdn.com/b/ie/archive/2011 ... r-ie9.aspx bzw. http://msdn.microsoft.com/en-us/library ... 85%29.aspx kommt nicht zufällig in Frage?

[yellowled]

Was mir von außen aufällt ist, dass http://yellowled.dyndns.org/s9y/ anscheinend nicht validiert

Einmal dt statt dl getippt. Danke, aber nein, das dürfte es nicht gewesen sein.

Deaktiviere ich im IE9 aber ActiveScripting

Stimmt. Grrr. Und jetzt der Reihe nach alle Skript durchhampeln. Die angle brackets-Geschichte sollte jQuery eigentlich abfedern.

Danke Dir.

YL

[yellowled]

So, jetzt wird es interessant.

Tatsächlich funktioniert es im IE9, wenn ich ein einziges JS entferne: Modernizr. Allerdings verwenden das auch meine plain html-Testcases.

Interessant ist das vor allem, da Modernizr u.A. dafür zuständig ist, dem IE<9 HTML5 beizubringen (der IE9 kann es nativ), indem die neuen semantischen Elemente einmal per document.write erzeugt und somit „angemeldet“ werden. Durchaus denkbar, dass darauf diese komische angle brackets-Geschichte greift. Mal testen.

EDIT: Tatsache. Mit Modernizr nichts zu wollen, aber: mit dem HTML5 shiv von Remy Sharp, der im Prinzip in puncto HTML5 haargenau dasselbe macht, geht es. Hm. Bleibt die Frage, warum es mit Modernizr in meinen HTML-Testcases geht.

YL

[Freudi]

Da ich gerne in der Luft herumspinne:
Das anscheinend funktionierende: modernizr-1.6.min.js
Das anscheinend Probleme verursachende: modernizr-1.7.min.js

Die Leerzeichen in den einleitenden CC werdens wohl kaum sein

[yellowled]

Da ich gerne in der Luft herumspinne:
Das anscheinend funktionierende: modernizr-1.6.min.js
Das anscheinend Probleme verursachende: modernizr-1.7.min.js

Den Zahn kann ich Dir ziehen: Ich habe beide Versionen schon ausprobiert, sie gehen beide nicht. Ebenso habe ich minifizierte und nicht minifizierte Versionen sowie unterschiedliche Arten, den Pfad zu Modernizr in S9y anzugeben, ausprobiert.

Die Leerzeichen in den einleitenden CC werdens wohl kaum sein

Nö, die sind auf http://netzgestaltung.net ja auch da.

Ich habe jetzt einfach mal Paul Irish eine E-Mail geschrieben, da der Bugtracker auf GitHub auch nichts zu Modernizr vs IE9 ausspuckte. Vielleicht ist das in einer unveröffentlichten Version bereits behoben, keine Ahnung. Abwarten. (Scheiß Zeitverschiebung, in San Francisco ist tiefe Nacht. )

YL

[Freudi]

Hm, dann bleibt ja nun nicht mehr viel außer einem Konflikt mit jQuery - was Du mir auch gleich um die Ohren schlagen wirst

[yellowled]

Hm, dann bleibt ja nun nicht mehr viel außer einem Konflikt mit jQuery - was Du mir auch gleich um die Ohren schlagen wirst

Natürlich hatte ich jQuery und speziell meine eigenen Skripte vor Modernizr als Erstes testweise entfernt, allein weil mir eher ein JS-Fehler zuzutrauen ist als den Entwicklern von jQuery oder Modernizr.

YL

[yellowled]

Wasserstand: Es könnte tatsächlich ein Bug in Modernizr 1.7 sein. Ich habe mir gerade den Sonntag mit einer Reihe Tests versaut und die Ergebnisse an Paul gemailt - schau'n 'mer mal.

YL

[Adramelec]

Kam da noch was ?