Immer wieder taucht ein Problemfall bei der Umsetzung von Webseiten auf: die Einbindung einer individuellen Schrift, die nicht über Betriebssysteme und Officeprogramme überall verteilt ist. Seit Kurzem ist die Einbettung mittels CSS über @font-face
sehr beliebt. Bei der Erstellung meines neuen Designs habe auch ich mich dieser Technik bedient. Doch leider ist sie nicht ohne Tücken.
Kurz nach meinem Relaunch bekam ich mit, daß die Schrifteinbettung sehr oft nicht funktionierte. In den letzten Wochen kam ich selten dazu, an meine Webseite zu denken, geschweige denn sie weiterzuentwickeln und kleinere Bugs auszumerzen. Heute widmete ich mich des Schriftenbugs. Seltsamerweise stellten IE6 und IE7 die seite wie gewünscht dar, IE8 und Firefox 3.5 hingegen nicht. Ich bin zwar hinter das Problem gekommen, doch leider öffnete sich ein neues.
Ich nutze für die Erstellung des Layouts das Framework YAML meines Freundes Dirk Jesse. Die Inhalte der CSS-Dateien werden bei YAML oft in media-Regeln gepackt. Offenbar haben die oben genannten Browser ein Problem damit, eine „@-Regel“ in eine weitere „@-Regel“ zu packen. Also habe ich die Schriftenregeln an den Anfang des Stylesheets gepackt und alles war wieder gut. Es sind oft die kleinen Dinge, über die wir stolpern.
Doch leider freute ich mich zu früh. Denn die genannten Änderungen führten zwar auf meiner lokalen Testumgebung zum Erfolg, auf dem Livesystem versagten aber nun alle Browser. Auch eine Auslagerung der Schriftregeln in eine separate Datei und die anschließende Löschung aller Kommentare brachte nichts. Ich habe die Schriften ein wenig geändert und muss leider akzeptieren, daß derzeit kein Browser meine gewünschte Schrift anzeigen will. Wenn ich wieder Zeit habe, werde ich mich des Problems wieder annehmen. Derzeit geht es nicht. Das ist bedauerlich, aber der Inhalt der Seite wird durch die andere Schrift schließlich nicht verfälscht. Und nur darauf kommt es an.
Ergänzung: Ich habe schon seit einigen Wochen immer wieder Probleme mit meinem Webspace. Ich kann derzeit nicht ausschließen, daß es irgendeine Kleinigkeit bei meinem Provider ist, die diese seltsamen Probleme hervorruft.
Ergänzung 2: Ich habe das Problem gelöst, bin aber sehr unzufrieden mit dem Ergebnis. Siehe meinen Kommentar weiter unten.
10. März 2010 um 14:38 Uhr
Hm, eigentlich sollten die Browser damit kein Problem haben, hast du da mal ein isoliertes Testcase für uns?
10. März 2010 um 14:42 Uhr
Ja, sie sollten nicht. Aber sie haben es in meinem speziellen Falle. Da die selben Dateien einmal lokal funktionieren und online nicht, tippe ich mittlerweile auf domainfactory, als den Übeltäter. Habe nur derzeit weder Musse noch Motivation, das auszutesten. Und einen isolierten Testcase habe ich derzeit nicht. Isoliert haben die Schrifteinbettungen vorhin auch funktioniert. Bis ich auf die Sache mit der @-Regel kam.
10. März 2010 um 15:09 Uhr
Ein Testcase zu diesem Szenario würde mich auch interessieren. Denn bisher hatte ich (abgesehen von der Schriftgrlättung) zum Glück keine Probleme mit der @font-face-Einbindung (wobei ich immer die Mo’ Bulletproofer @Font-Face CSS Syntax von Richard Fink verwende).
10. März 2010 um 15:34 Uhr
Interessanterweise funktioniert mein Testcase mit exakt den gleichen Dateien, wie mein WordPress-Template. Ich habe nur die Struktur aus der Seite gelassen, alles andere ist gleich. Kann es sein, daß die Browser nun mit den Pfaden nicht zurechtkommen, die evtl. von WordPress zurechtgebogen werden? Sieht mir nach einem Pfadproblem aus, denn schließlich funktioniert es nun ohne WordPress drumherum. Vielleicht sollte ich – wie ich es schonmal vorhatte – YAML aus dem WordPress-Template ausgliedern.
10. März 2010 um 20:51 Uhr
Ich habe font-face schon zwei mal mit WordPress eingesezt, ohne Probleme, in jedem Fall waren aber die Stylesheets nicht über eine @ Regel eingebunden. Diese meide ich, da die Performance etwas schlechter ist (habe gerade den Link dazu nicht)
11. März 2010 um 9:55 Uhr
Ich habe das Problem gelöst, obgleich ich damit sehr unzufrieden bin. Es hatte offenbar etwas mit Pfaden zu tun. Ich habe den Verweis auf die Schriften nicht relativ zum Stylesheet gesetzt, sondern absolut zum Server – also einen Slash vor dem ersten Ordner gesetzt. Nun funktioniert es zwar, das Stylesheet greift aber nicht mehr auf die Dateien im eigentlich gewünschten Unterordner des Themes zurück, sondern auf einen anderen Ordner auf meinem Server. Ein absoluter Pfad direkt in das Theme hinein hat allerdings auch nicht gefruchtet. Es bleibt ein wenig unbefriedigend, aber es funktioniert und das ist die Hauptsache.
13. März 2010 um 8:36 Uhr
Schön, dass jetzt eine gut lesbare Schrift im Einsatz ist. Da macht das Lesen der Artikel gleich viel mehr Spaß!
Der basemod.css entnehme ich, dass der Font Delicious mittels @font-face eingebunden wird. Gefällt mir sehr gut.
Da werde ich mich bei einem Relaunch auch mal an @font-face versuchen. Danke für die Hinweise auf mögliche Probleme im Zusammenspiel mit WordPress und YAML und wie man sie in Griff bekommen kann.