Natürlich ist es mal wieder die Internet-Explorer-Familie, die extreme Perdormanceprobleme aufweisen, aber auch sämtliche andere Browser bekleckern sich im Umgang mit der noch recht jungen Technologie kaum mit Ruhm. FOUT – flash of unstyled text ist dabei noch das kleinste Problem, wenn die Fontdateien nicht schnell genug vom Server geliefert werden. In IEs wirkt sich das noch schlimmer aus: bis zum Download des Fonts zeigt Bill Gates Rache gar nichts an. In anderen Browsern bleiebn nur die Textteile, die mit @font-face gerendert werden sollen unsichtbar, Firefox zeigt die Ausweichschrift(en) an.

Solchen (und den anderen im Text genannten) Performancefallen kann man natürlich mit Caching, Zipping und ähnlichzen Techniken begegnen. Ob man sich aber den Aufwand leisten will, bereits zum jetzigen Zeitpunkt, ich stelle das mal in Frage…

Mit @font-face lassen sich Schriften in Webseiten einbetten. Machen Sie das!

Ok, es ist soweit, mit dem neuen Firefox 3.5 (und Safari 4 und Opera 10beta), steht immer mehr Nutzern unserer Websites Fontembeddingdownloading¹ zur Verfügung. Damit widerum steht der flächendeckenden Umsetzung typographisch ordentlich gestylter Websites nicht mehr viel im Weg, ausser natürlich die IE-Familie, aber die ignorieren wir hier einfach einmal.²

Und so geht’s

Das obige Beispiel nutzt das Embedding, der Code dafür sieht ungefähr so aus:

@font-face {
    font-family: Kaffeesatz;
    font-weight: normal;
    src: url(fonts/YanoneKaffeesatz-Regular.otf) format('opentype');
}
h1 {
	font: normal 3em/120% Kaffeesatz, sans-serif;
	text-shadow: 1px 1px 1px #eee;
}

Der genutzte Font ist die unter CC Lizenz stehende Kaffeesatz. Der Code ist vielleicht nicht ganz selbst erklärend: mit @font-face legen wir selbst eine Font fest, den Namen der font-family kann man dabei frei wählen, ein dem Font nahe stehender Name empfiehlt sich natürlich. Als src wird der Pfad zum OTF- oder TTF-File angegeben, danach noch das format. Fertig. Damit steht uns die font-family „Kaffeesatz” zur weiteren Nutzung zu Verfügung. Das H1 macht auch gleich Gebrauch davon, noch ein wenig versüsst mit etwas CSS3-text-shadow (wenn wir auf den IE sch…sen, dann aber richtg).

Mehr Gewicht, bitte

Folgendes ist zu beachten: wir haben bis hier nur den Font für die font-weight normal definiert. Wollen wir eine bolde Schrift, muss ein Font dafür embedded werden, und zwar bspw. so:

@font-face {
    font-family: Kaffeesatz;
    font-weight: normal;
    src: url(fonts/YanoneKaffeesatz-Regular.otf) format('opentype');
}
@font-face {
    font-family: Kaffeesatz;
    font-weight: bold;
    src: url(fonts/YanoneKaffeesatz-Bold.otf) format('opentype');
}
h1 {
	font: normal 3em/120% Kaffeesatz,sans-serif;
	text-shadow: 1px 1px 1px #eee;
}
h2 {
    font: bold 2em/120% Kaffeesatz, sans-serif;
    text-transform: uppercase;
}

In diesem Falle würden die H2s bold gesetzt, da wir hierfür YanoneKaffeesatz-Bold.otf embedded haben. Ähnliches können wir nun auch mit font-style: italic anstellen.

Nochmal zurück zur Fettung: Safari kann einige Fettungsstufen mehr anzeigen als Firefox. Unterstützt wird eine genauere Abstufung des Fettungsgrades, wenn man bspw. einen Font hat die Kaffeesatz. Das kann dann so aussehen:

@font-face {
    font-family: Kaffeesatz;
    font-weight: 100;
    src: url(fonts/YanoneKaffeesatz-Thin.otf) format('opentype');
}
@font-face {
    font-family: Kaffeesatz;
    font-weight: 300;
    src: url(fonts/YanoneKaffeesatz-Light.otf) format('opentype');
}
@font-face {
    font-family: Kaffeesatz;
    font-weight: 400;
    src: url(fonts/YanoneKaffeesatz-Regular.otf) format('opentype');
}
@font-face {
    font-family: Kaffeesatz;
    font-weight: 700;
    src: url(fonts/YanoneKaffeesatz-Bold.otf) format('opentype');
}

Das geht sicherlich auch mit keywords wie „light” oder „bolder” etc.

Das Fontrendering unterscheidet sich mitunter, links Firefox, rechts Safari 4 (Mac).

Fonts von der Platte zuerst

Was ja auch angehen kann, ist dass man eher einen Font nutzen möchte, der sowieso schon lokal vorhanden ist und nur wenn dieser nicht vorhanden ist, will man einen Download anbieten. Geht auch, wie man bei John Dagget nachlesen kann, mit der Eigenschaft „local”:

@font-face {
  font-family: NeueHelvetica;
  src: local("Helvetica Neue"),
       local("HelveticaNeue"),
       url(fonts/MgOpenModernaRegular.ttf);
}

Hier sind zwei local angegeben, über diese Liste wird iteriert, genauso wie in der normalem font-family Zuweisung, wo die Schriften durch Kommata getrennt werden (das diese Zusammenstellung von Namen nicht immer ganz einfach ist, lesen wir bei Herrn Preidel).

Und nun?

Natürlich sollte man nur Schriften nehmen, die man auch fürs embedding benutzen darf, sonst gibt’s schnell Lizenzärger. Hier gibt’s ein paar freie Schriften, die das ausdrücklich zulassen. Ach ja und zum guten Schluss, sollte man font-size-adjust auf keinen Fall vergssen.

Updates

¹⁾ Von „Embedding“ zu sprechen ist eigentlich nicht richtig, weil der Font tatsächlich auf den Rechner des Nutzers heruntergeladen wird. Das schlägst sich natürlich auch in der Größe der Website nieder und ist auch für die Lizenzfrage nicht unerheblich.

²⁾ Na gut, ich hab noch einen Link aus meinen Bookmarks geangelt, der mehr in Sachen IE verrät.

→

Nun versucht Opera aber bei uns Webentwicklern zu glänzen und das muss man nun mindestens melden, würde der Internetredakteur sagen. Mit Opera Dragonfly (Aplha-Version) bringt man eine Debugging-Umgebung für den Opera-Browser heraus, die sich ganz eindeutig an Firebug, meinem Liebling-Firefox-Tool, orientiert. Damit kann man nun Reiten, Schwimmen, … quatsch, Dragonfly bringt:

• einen Javascript Debugger mit Tracing, Breakpoints und Stepping
• eine Fehlekonsole liefert einen Überblick über alle auftretenden JS- und CSS-Fehler
• eine Kommandozeile für Javascript
• einen DOM-Inspektor, mit dem man sich durchs DOM und die Source hangeln kann
• und einen CSS-Inspektor.

Das klingt doch ziemlich nach Firebug. Die Alpha-Version funktioniert aber natürlich noch nicht so reibungslos. Das wird jedenfalls ein nettes zusätzliches Feature, wenn ich denn mal Seiten im Opera testen muss.

[Update: Manuel Bieh sieht das gut begründet anders.]

Anders als in den Staaten vielleicht, ist es bei uns wenig verwunderlich, dass das mobile Web in den Kinderschuhen stecken bleibt: die Anbieter legen sich schließlich nicht gerade ins Zeug, wenn es darum geht, Internetdienste zur Verfügung zu stellen. Die Preise für Flatrates in diesem Bereich sind noch astronomisch (vor allem, wenn man das zusätzlich zu den Kosten des stionären Webs rechnet). Und Einzelverbindungen sind stellenweise so teuer, dass es sich eher um Abzocke handelt, die darauf ausgerichtet ist, Leuten, die aus Versehen die Internettaste ihres Handies betätigen abzukassieren.

Dementsprechend bleiben nur die Earlyadopter (immer noch), die natürlich nicht mit dem durchschnittlichen 1-Euro-Device das Netz unsiche machen, sondern eben mit iPhone oder Opera mini. Bei diesen Browsern jeodch bekommt man mit ein paar mobilen bzw. spezialisierten CSS wesentlich mehr Ergebnis, als mit teuer auf “mobile” angepassten Anwendungen. Warum einen Javaclient für Gmail, wenn Gmail direkt funktioniert? Eben.

Zum fehlenden, oder schlechtem Traffic (Beattie says traffic at Mowser was poor and 80% of it was made up of porn seekers.), kommen dann noch (wieder bei uns in D zutreffend) die Abzocker, die mit dem angeblichen Trend unwissenden Entscheidern Hunderttausende für nutzlose mobile Service aus den Rippen gequatscht haben, die inzwischen technisch schon überholt sind (WAP bspw.). Das alles wirft ein düsteres Licht auf die Idee “mobiles Web”.

Und lässt gleichzeitig das ganz normale Web wieder erstarken, denn das ist der eigentliche mobile Trend: “normal Web on phone” nenne ich das jetzt mal. Hätte man wissen können…

Opera ist mit seinem Handybrowser ja angetreten, das iPhone zu schlagen… im ersten Moment scheint das jetzt lächerlich zu klingen, denn der Browser kann halt nur so gut sein, wie das Wirtshandy, aber: auf meinem W910i jedenfalls macht er ganz schön ‘was her. Im Querformat kann man damit schon richtig was sehen. Und Opera Mini ist ja auch noch ein super Feedreader. Wie gewohnt respektiert Opera Mini zur Verfügugng gestellte CSS für “handheld”, schrumpft sich aber selbst die Bilder in die richtigen Größen. Über den opera-eigenen Proxy werden Seiten, die nicht spezielle CSS mitbringen, zunächst in einer extrem verkleinerten Übersicht dargestellt und man kann dann von dort hineinzoomen. Das ist schonmal nett.

Die Beta bringt noch einiges Neues dazu:

• insgesamt schneller…
• Suche innerhalb einer aufgerufenen Webseite
• Download (Download! Download! Download!)
• Seiten abspeichern

Man kann schon sehen in welche Richtung die Sache geht. Macht mir jedenfalls ziemlichen Spass. So ohne iPhone. ;)

Ich empfehle dazu übrigens wie immer zeit.de als Testseite (nicht die Mobilversion…!), …