Exit Cufon en sIFR, welkom @font-face?
Bij het maken van een website zijn er maar een aantal ‘standaard’ fonts die je kan gebruiken, fonts waarvan je zeker bent dat ze op elk platform beschikbaar zijn. Vaak zijn deze fonts echter saai, oubollig of passen ze gewoonweg niet in het ontwerp van de website. In een vorige blogpost kwamen Cufon en sIFR al ruimschoots aan bod. Een nadeel hier is dat het font nog een keer veranderd gaat worden door JavaScript waardoor de tekst soms flikkert. Zou het niet veel mooier zijn als we meteen een ‘exotisch’ font in konden laden via CSS? Hoog tijd om @font-face te leren ontdekken.
Met @font-face is het mogelijk om fonts van op de webserver in te laden, zodat deze doorheen de website gebruikt kan worden. In tegenstelling tot Cufon en sIFR gaat het hier niet om afbeeldingen of flash, maar wel om volwaardige tekst. Het is echter net het embedden van deze fonts waar het schoentje knelt. Niet ieder lettertype mag je zomaar vrij gebruiken als embedded font op een website. Kijk hiervoor dus zeker de licentie van het font na. Gelukkig zijn er een aantal alternatieven, waarbij je het font niet zelf host, maar linkt naar een externe service met fonts die zonder problemen gebruikt mogen worden op het web. Een overzicht van twee services die dit aanbieden.
Typekit
Typekit biedt een hele reeks van fonts aan die je kan gebruiken op een website (momenteel meer dan 400). Je hebt hiervoor wel een (betalende) account van Typekit nodig. Voor net geen $100 per jaar (prijs mei 2010) ben je eigenaar van een 'Performance' account. Eenmaal in het bezit van een account kan je op de Typekit website een profiel aanmaken dat je kan koppelen aan één of meerdere domeinen. Je geeft aan welke elementen/classes welk font moeten gebruiken. Belangrijk is ook om een standaard lettertype te selecteren waar de browser van de bezoeker op terug kan vallen in het geval hij geen @font-face eigenschap ondersteunt.
Zodra alle instellingen goed doorlopen zijn kan je je kit exporteren. Vanaf dat moment is de kit bruikbaar binnen de domeinen die je bij de instellingen hebt opgegeven. Typekit zal je een stukje JavaScript code geven die je op je website moet inladen. Hierdoor gebruiken alle opgegeven elementen/classes onmiddellijk het ‘exotische’ font.
Alle informatie over Typekit kan je nalezen op de Typekit website.
Google font directory
Een andere mogelijkheid is gebruik maken van Google font directory, momenteel nog in bèta. Via de Google Font API kan je een aantal fonts inladen op jouw website. De lijst met beschikbare fonts is wel een pak kleiner (momenteel 18) dan bij Typekit. Het voordeel van Google font directory zit dan weer in het gebruiksgemak. Met slechts één regel HTML code voeg je één of meerdere fonts toe aan een webpagina, in verschillende stijlen als dat nodig is. Via deze API zijn er nog tal van andere mogelijkheden, die stof genoeg geven voor een aparte blogpost.
Alles over Google font directory kan je nalezen op de Google font directory pagina.
Enkele voordelen
Aangezien er geen afbeeldingen/flash bestanden gegenereerd moeten worden is het gebruiken van @font-face stukken sneller dan Cufon of sIFR. Het font wordt eenmalig ingeladen en doorheen de volledige website als een gewoon lettertype behandeld. Daardoor is de tekst ook perfect te selecteren en te kopiëren, iets wat bij Cufon of sIFR nog wel eens mis wou gaan.
Daarnaast is ook het opzetten vele male sneller dan Cufon of sIFR opzetten. In principe is nu een link leggen voldoende om het font te kunnen gebruiken. Dit in tegenstelling tot bijvoorbeeld het genereren van JavaScript bestanden voor specifieke fonts.
Enkele nadelen
Nuttig om weten dat @font-face lang niet in elke browser werkt, of althans niet het verwachte effect heeft. Daar waar je met bijvoorbeeld FireFox (3.5+) meerdere stijlen van eenzelfde font kan definiëren (bold, italics ...), gaat dit niet met Internet Explorer voor eenzelfde font.
Conclusie
Wanneer je als webbedrijf optimaal gebruik wilt maken van het embedden van fonts via Typekit of Google font, moet je er wel voor zorgen dat designers zich aan een bepaalde reeks fonts houden. Ik denk dat het aanbod van Typekit voldoende groot en gevarieerd is voor het gebruik op de meeste websites.
Het gebruik van @font-face is iets dat in de toekomst meer en meer gebruikt zal worden. Ikzelf ben alvast te vinden voor deze nieuwe speler, die wat mij betreft een streepje voor heeft op Cufon en sIFR.
Wat denken jullie van het embedden van niet-standaard fonts via CSS? Geef gerust jullie mening via het commentaarveld hieronder.
6 Reacties op deze blogpost:
Persoonlijk vind ik dat het nog iets te vroeg is om van start te gaan met @font-face implementaties voor gewone websites. Voor applicaties is het natuurlijk wel een gemak en zeker wel een optie.
Cufon maakt gebruik van VML wat zeer snel rendert in een browser (niet te vergelijken met sIFR). Je kan tekst selectie van Cufon inschakelen alleen werkt het nog niet in Opera waardoor de maker van Cufon het nog niet wilt vrijgeven. De changelog van de 1.10 release ziet er veelbelovend uit.
Ik blijf alvast nog een tijdje bij Cufon.
En zeker niet te vergeten is fonts.com (van Monotype imaging), dit wordt denk ik in de toekomst de grootste speler op de 'font-markt' voor het web! Met duizenden fonts beschikbaar voor het web.
Ik zou zeggen, gaan met die @font-face... Spijtig van/voor die ene browser. Ik ga er alvast mee van start!
De impact die @font-face zal hebben moeten we ook niet te hoog inschatten. Als je bv. kijkt naar 'print' dan zie je dat er maar een handvol lettertypes bruikbaar zijn voor leesbare tekst, en net die gebruiken we al in onze sites. Ook is het een gouden regel dat je als designer slechts tot 3 (liefst 2) verschillende lettertypes gebruikt in een design, zo houd je de look simpel en consistent.
Ik zie het dan ook alleen gebruikt worden voor titels. Ok, en misschien hier en daar een banner, alhoewel we eerder naar images zullen grijpen.
State of webfonts 2010:
Cufon is niet selecteerbaar, wat het onbruikbaar maakt voor bijna alles op een website; maar het is wel erg makkelijk te implementeren.
De fonts die door @font-face getrokken worden zien er verschrikkelijk uit op Windows (slechte anti-aliasing! Vervorming!). De fonts in de google font directory zijn veelal rommel (de bold versie van Droid is bijvoorbeeld optisch groter dan de regular versie, en het lettertype heeft geen italic). Je kan er niet van uitgaan dat de hosted service blijft bestaan, dus je hangt af van een extra 3rd party.
Om sIFR te kunnen gebruiken heb je een kopie van Adobe Flash nodig. Het is technisch nog altijd de beste oplossing maar een hel om te implementeren.
Geldt voor alle 3: een gigantische performance hit.
Ik vind het wel een leuk iets dat font-face. Onlangs nog een uitgebreid artikel over gelezen in het .net magazine mei 2010 en ben zo op fontsquirrel.com uitgekomen wat een leuke site is voor webtype resources. Vooral omdat het gratis is en je dus gemakkelijk eens kan experimenteren.
Wolf: Geldt voor alle 3: een gigantische performance hit.
Valt wel mee. Als je een subset gebruikt van een font en je doet het op de CSS3/@font-face-manier merk je het verschil niet tussen een native font en een custom font. Je hebt dan een eenmalige download van rond de 30 KB, en dat is zo geladen.
Met Cufon hangt het vooral af hoe groot je DOM is. Met kleine pagina's zie je geen flikkering. Je kan Cufon overigens wel selecteerbaar maken, alleen ziet dat er niet heel mooi uit:
.cufon {
user-select: all;
-moz-user-select: all;
-webkit-user-select: all;
}
sIFR begin ik niet meer aan. De tekst is niet selecteerbaar als je niet begint met selecteren binnen het flash object, en random flashobjecten binnen je markup geeft altijd gedoe met styling en line-height e.d.. Cufon is qua implementatie een stuk makkelijker en sneller.
Ik gebruik nu @font-face, al probeer ik custom fonts nog steeds te vermijden vanwege de anti-aliasing in Internet Explorer. Ik hoop dat dit is opgelost in Internet Explorer 9.