Met @font-face eigen aangepaste fonts (webfonts) gebruiken - uitleg

Korte omschrijving

Vanaf internet gedownloade eigen fonts (webfonts) gebruiken om tekst weer te geven. Webfonts hebben niet de nadelen van bijvoorbeeld plaatjes, ze gedragen zich volledig als normale tekst.

Opmerkingen

• Lang niet alle fonts mogen zomaar worden gebruikt als webfont. Zelfs als een font in je eigen computer zit, of als je hebt betaald voor een font, betekent dat nog niet dat je het als webfont mag gebruiken.

  Als je (grote) problemen wilt voorkomen, bekijk dan altijd de licentie waaronder het font valt. Op de pagina met links vind je onder CSS → Fonts 'n aantal sites, waar vrij te gebruiken fonts te vinden zijn. En als je zelf even zoekt op internet, vind je 'n nog veel grotere hoeveelheid vrij te gebruiken fonts.

  Dit is echt iets om even goed naar te kijken. Bij afbeeldingen, videos, artikelen, enz. die zonder uitdrukkelijke toestemming worden overgenomen of verspreid, is een rekening van vele honderden of zelfs duizenden euro's inmiddels heel normaal. Als je het van je site verwijdert op het moment dat je zo'n rekening ontvangt, kom je vaak toch niet meer onder betalen uit.

  Voor zover ik weet, gebeurt dit op het moment van schrijven nog niet met fonts, waarvoor je geen licentie hebt. Maar het zit er dik in dat dit in de toekomst wel zal gaan gebeuren.

• Bij het maken van dit voorbeeld heb ik veel gehad aan de volgende sites: paulirish.com, fontsquirrel.com, smashingmagazine.com en fontspring.com. Meer links naar sites over fonts zijn te vinden op de pagina met links.
• Lang niet alle fonts zijn geschikt als webfont. De fonts die bij het besturingssysteem worden geleverd, zijn precies zo gemaakt dat ze in dat systeem goed worden weergegeven. Dat is met webfonts niet altijd het geval. Daarom moeten webfonts op zoveel mogelijk systemen in zoveel mogelijk browsers worden getest. Zie verder bij Bekende problemen.
• De in dit voorbeeld gebruikte fonts Ubuntu Mono en Jinky zijn in de download bijgesloten in de map '098-fonts'. In die map zitten ook de licenties, waaronder deze fonts vallen.
• Voor het omzetten van de fonts naar webfonts en voor het maken van de css-regels met @font-face is gebruik gemaakt van de generator op fontsquirrel. Dit is veel makkelijker dan dat je het zelf handmatig gaat lopen doen. De gegenereerde css is nog wel iets aangepast. Wat en waarom er is aangepast, is te vinden in de Beschrijving van code en css.
• Als de webfonts het niet of niet altijd doen en je gewone standaardfonts ziet, kan dat heel veel oorzaken hebben. Mogelijk staat een van die oorzaken (en hopelijk de oplossing) bij Bekende problemen.

• Het laden van webfonts kost tijd. Hoe meer fonts je gebruikt, hoe meer de laadtijd toeneemt. Als je van een font naast de normale variant bijvoorbeeld ook de cursieve variant gebruikt, moeten er al twee fonts worden gedownload. Als je ook nog de vette variant gebruikt drie. In het voorbeeld worden voor Ubuntu Mono vier fonts gedownload.

  Als je geen speciale cursieve (of vette, of ...) variant gebruikt, zijn er minder fonts te downloaden. Maar als je vervolgens wel cursief, vet, en dergelijke op de pagina gebruikt, probeert de browser zelf cursief en dergelijke maken. Het resultaat daarvan is in de regel niet om aan te zien. In het voorbeeld is het font Jinky het slachtoffer van deze typografische mishandeling geworden. Meer hierover bij Bekende problemen.

• Omdat je nooit honderd procent zeker kunt weten dat een webfont goed wordt geladen, is het absoluut nodig voor een alternatief font (in vloeiend Nederlands: een fallback-font) te zorgen. Meer hierover bij de Beschrijving van code en css.

Links in deze uitleg, vooral links naar andere sites, kunnen verouderd zijn. Op de pagina met links vind je steeds de meest recente links.

Alles op deze site is gemaakt op een systeem met Linux (Kubuntu). Daarbij is vooral gebruik gemaakt van Quanta Plus, GIMP en Firefox met extensies. De pdf-bestanden zijn gemaakt met LibreOffice.

Vragen of opmerkingen? Fout gevonden? Ga naar het forum.

Achterliggend idee

Zo'n beetje vanaf het ontstaan van internet zijn mensen bezig manieren te vinden om, net als op papier, eigen fonts te kunnen gebruiken. Helemaal zoals op papier zal het nooit worden, omdat niet elk browservenster even groot is, lettergroottes kunnen worden veranderd, enz. Op papier heb je dat allemaal volledig in de hand, maar niet in een browser.

Maar het zou al schelen, als je in ieder geval je eigen lettersoort zou kunnen gebruiken.

Alle methoden om eigen fonts te gebruiken hebben grotere of kleinere nadelen. Zo kan bijvoorbeeld een afbeelding worden gebruikt, waaronder gewone tekst staat verstopt. Die gewone tekst kan dan door spraakbrowsers, zoekmachines, en dergelijke worden gebruikt, terwijl de bezoeker de afbeelding met tekst ziet. Maar tekst op een afbeelding kan niet worden geselecteerd, gekopieerd, enz. En de lettergrootte is niet goed aan te passen.

De laatste jaren zijn allerlei methoden met JavaScript en/of Flash ontwikkeld, mede om dit soort nadelen te ondervangen. Op de pagina met links staat een aantal sites, die meer info over dat soort methoden geven. Ook deze methoden hebben weer hun eigen nadelen, zoals dat je van JavaScript en/of Flash afhankelijk bent. En sommige methoden hebben wat betreft ingewikkeldheid wel wat overeenkomsten met een cursus Grieks. Niettemin waren die methoden soms goed bruikbaar, als je beslist eigen fonts wilde gebruiken.

Tot er 'n betere oplossing kwam: @font-face.

Met behulp van @font-face is het mogelijk om willekeurige fonts vanaf internet te downloaden en op de computer van de bezoeker te gebruiken. De bezoeker hoeft de fonts niet zelf geïnstalleerd te hebben. Deze methode maakt het gebruik van afbeeldingen, JavaScript, Flash, enz. overbodig.

'Tot er 'n betere oplossing kwam' klopt feitelijk niet helemaal. In Internet Explorer bestaat @font-face al heel lang, en het was ook in css 2 opgenomen. Maar omdat alleen Microsoft het had geïmplementeerd, en dan ook nog met bedrijfseigen methoden, is het in de specificatie voor css 2.1 eruit gehaald.

Kennelijk van de weeromstuit hebben inmiddels alle browsers het ingebouwd. Met ingang van Internet Explorer 9 ondersteunt ook Microsoft een standaardmethode. En in de specificatie voor css3 is het weer opgenomen.

Ik ga me niet aan de achtergronden hiervan wagen, want zonder astroloog, wichelroedeloper en 'n ISO-gecertificeerde toverkol is dit soort politiek niet te volgen.

Omdat er voor webfonts doodgewone, normale tekst wordt gebruikt, kent deze methode eigenlijk geen nadelen, buiten het downloaden van de benodigde fonts. Er is geen enkele invloed op dingen als vergroten, selecteren, kopiëren, enz. Spraakbrowsers en zoekmachines hebben dan ook geen enkel probleem met @font-face.

Het apenstaartje in @font-face geeft aan dat het om 'n bijzondere css-instructie gaat. De instructie is niet aan één of meer elementen gekoppeld, zoals bij css meestal het geval is. In dit geval moeten er fonts beschikbaar worden gemaakt. Die fonts zijn dan later op de normale manier te gebruiken, net zoals 'gewone' fonts.

Het enige echt grote nadeel van deze methode is dat het downloaden van de fonts tijd kost. Maar voor bijvoorbeeld mobieltjes kan dat wel 'n heel fors nadeel zijn. Na tien minuten laden lees je op je mobieltje in 47 prachtige fonts dat je laatste trein één minuut geleden is vertrokken. Meteen daarna verschijnt een vriendelijke melding van je provider dat bij het laden van het veertiende font je datalimiet is overschreden. Het lijkt mij ietwat twijfelachtig, of zo'n bezoeker daarna loeiend van geluk enthousiast reclame gaat lopen maken voor je site.

Mij persoonlijk zeggen webfonts trouwens vrij weinig, want ik gebruik internet voornamelijk voor informatie. Voor mij is eigenlijk alleen van belang dat de letter goed leesbaar is.

Maar voor grafische sites en dergelijke kan ik me er wel iets bij voorstellen. En mijn persoonlijke voorkeur is natuurlijk niet echt 'n doorslaggevend argument voor de miljarden pagina's op internet. Hoezeer ik dat in mijn meer megalomane momenten ook betreur.

Over Chinese webfonts heb ik trouwens - heel uitzonderlijk voor mij - geen mening. Dat zijn voor mij allemaal al prachtige schilderijtjes.

Wat ik maar wil zeggen: je moet je altijd even afvragen, of het voor jouw site echt zinvol is. Als je alleen treinvertragingen of het weerbericht wilt melden, lijkt het gebruik van webfonts me nogal overdreven.

Op dit moment is één van de nadelen van @font-face nog, dat voor verschillende browsers verschillende formaten van een font nodig zijn. Jij ziet op je scherm gewoon de letter 'A', maar hoe die letter wordt gemaakt, kan enorm verschillen tussen besturingssystemen en browsers. De instructies hoe zo'n 'A' moet worden getekend, kunnen op verschillende manieren worden opgeslagen. Ongeveer zoals mensen verschillende talen kennen.

Inmiddels is er wel 'n standaard ontwikkeld voor webfonts, maar het zal nog wel even duren voor browsers en systemen die oudere formaten gebruiken helemaal zijn uitgestorven. Op die formaten kom ik later nog terug. Hier alvast even de namen: Embedded Open Type (eot), Web Open Font Format (woff), TrueType (ttf) en Scalable Vector Graphics (svg).

Tussen verschillende fonts zit nogal wat verschil in omvang, en dus in de tijd die het kost om een font te downloaden. Een font als Times New Roman Bold met, op mijn computer, 1379 tekens is natuurlijk veel groter dan een font dat alleen het alfabet en cijfers bevat. Bij die 1379 tekens zit onder andere het volledige Grieks en cyrillische alfabet, iets wat op de meeste westerse sites niet echt nodig zal zijn. En dus ook niet gedownload hoeft te worden.

Als je de generator op fontsquirrel (waar ik later nog op terugkom) gebruikt om de css en de webfonts automatisch aan te laten maken, worden bij de standaardinstellingen van de generator alleen de in het westen gebruikelijke tekens uit het font gebruikt: het alfabet, cijfers, diakritische tekens (accenten), en dergelijke. Daardoor wordt Times New Roman Bold (in ttf-formaat) teruggebracht van 326,1 kB naar 40,3 kB.

In het voorbeeld worden Jinky en Ubuntu Mono gebruikt. Jinky varieert, afhankelijk van het formaat, van 31,8 tot 150,2 kB. Ubuntu Mono Regular varieert, afhankelijk van het formaat, van 103 tot 408,1 kB. Het goede nieuws is dat het formaat van de toekomst, woff, met stip het kleinst is.

Maar hoe dan ook: voor dit voorbeeld moeten vijf fonts worden gedownload die samen in het gunstigste geval, als de browser het woff-formaat gebruikt, 207,3 kB groot zijn.

En in het ongunstigste geval, bij het svg-formaat, zijn de vijf fonts samen maar liefst 854,3 kB groot. Als je 'in het echt' zoveel moet downloaden om 'n paar regels tekst weer te geven, zijn alle verhoudingen natuurlijk compleet zoek.

Er bestaat een mogelijkheid om te kijken, of het font al aanwezig is in de computer van de bezoeker, zodat het niet gedownload hoeft te worden. Maar meestal zul je hier niet zo heel veel aan hebben, omdat je in de regel natuurlijk juist fonts wilt gebruiken die wat apart zijn en dus nog niet geïnstalleerd zullen zijn op de computer van de bezoeker. Bovendien moet je de exacte naam van het font (en eventueel de variant daarvan) weten, anders wordt het niet gevonden.

Je mag meerdere lokale fonts opgeven, dus je kunt wel meerdere manieren om de naam te schrijven uitproberen. Want natuurlijk verschillen die namen soms weer enigszins bij de diverse besturingssystemen. (Internet Explorer 8 en eerder kijken overigens alleen naar het eerste lokale font, dus daar kun je maar één naam gebruiken voor een lokaal font.)

Eén van de gebruikte lettersoorten in dit voorbeeld is Ubuntu Mono. Daarvan weet ik zeker dat het aanwezig is op mijn Linux-computer. Het is dus overbodig om het te downloaden. Daarom is aan de css voor het Ubuntu-font local toegevoegd met de namen van de Ubuntu fonts, zoals die in mijn computer zitten. Hierdoor wordt eerst gekeken, of de fonts al aanwezig zijn op de computer. En omdat dat zo is, worden ze niet gedownload, maar worden de fonts uit mijn computer gebruikt.

Op mijn Windows-computer is Ubuntu Mono niet aanwezig, en daar wordt Ubuntu Mono dan ook gewoon gedownload.

(Aanvulling 7 augustus 2012: het gebruik van local zorgt ervoor dat webfonts niet werken in de meest gebruikte versie van Android browser. Zie verder bij Bekende problemen.)

De benodigde tijd om de fonts te downloaden gaat nog meer spelen, als van een font ook cursieve, vette, enz. varianten worden gebruikt. Voor elke variant van een font moet een apart font worden gedownload.

Als een font geen aparte cursieve en dergelijke variant heeft, kun je toch proberen cursief, vet, enz. te gebruiken. In dat geval probeert de browser er zelf cursief en dergelijke van te maken. Let wel: proberen.

Het in het voorbeeld gebruikte font Jinky heeft maar één uitvoering: gewone normale standaardtekst. Geen vet, geen mager, geen cursief. Er hoeft dus maar één font gedownload te worden. Maar als je de browser van dit ene standaardfont zelf cursief en dergelijke laat maken, zie je waarom ik hierboven het woord 'proberen' heb gebruikt: het ziet er niet uit. Het is niet de ontwerper van het font, maar de browser die er het beste van probeert te maken. Bij Bekende problemen is wat meer te vinden over het droef stemmende resultaat van de inspanningen van de browser.

Als een font geen aparte cursieve, vette, enz. variant heeft, zou je het ook niet cursief, vet, enz. moeten weergeven. Een browser is niet bedoeld om complexe grafische handelingen uit te voeren, zoals cursief maken van een normale letter.

In principe wordt een font pas gedownload, als het wordt gebruikt. Als je in de css een cursieve variant definieert, maar die variant niet gebruikt, wordt het cursieve font ook niet gedownload. Behalve bij Internet Explorer 8 en eerder: die downloaden elk font dat ze tegenkomen in de css, of ze het nu gebruiken of niet. Het is dus beter niet-gebruikte varianten gewoon helemaal weg te laten uit de css.

De fonts die na installatie van een besturingssysteem in een computer aanwezig zijn, zijn speciaal ontworpen om in dat systeem goed te worden weergegeven. Bij webfonts is dat niet (altijd) het geval. Daardoor kan de weergave nogal tegenvallen. Uitgebreid testen op meerdere systemen in meerdere browsers is daarom uiterst belangrijk.

Omdat het webfont, om wat voor reden dan ook, wel 'ns niet goed in de browser kan aankomen, moet je net zoals altijd alternatieve fonts opgeven. En daar kan ook 'n probleem ontstaan: die fonts kunnen iets kleiner of, erger, net iets groter zijn. En als ze net iets groter zijn, kan je prachtige pagina-indeling met floats net niet meer passen. Waardoor je prachtige, typografisch perfect verantwoorde openingspagina voor het Letterkundig Museum opeens meer geschikt is voor een campagne ter bevordering van het bezoek aan de Drentse hunebedden.

Om dit probleem op te lossen heeft css3 de eigenschap font-size-adjust. Helaas werkt die eigenschap op dit moment alleen in Firefox. Hoewel, werken... Het is mij niet gelukt ook maar enig verschil te zien, dus ik vraag me af of dit echt al goed werkt in Firefox.

Maar goed, leuke toekomstmuziek.

Op dit moment is het het veiligste alternatieve fonts op te geven, die even groot zijn als het webfont.

En nu komt er iets ongelooflijks: Internet Explorer kon als eerste met @font-face overweg, al vanaf versie 4. Weliswaar was dat nog niet volledig, maar toch. Helaas werkte dit alleen maar met 'n formaat font, dat door Microsoft is ontwikkeld en alleen in Internet Explorer werkt en niet in andere browsers.

Feitelijk was dit tot voor kort gewoon 'n zootje: in totaal waren er vier verschillende soorten fonts. Gelukkig zijn de browsermakers het eens geworden over één formaat: woff. Dit wordt inmiddels door vrijwel alle browsers en systemen ondersteund.

Maar omdat er nog veel oude browsers en systemen in omloop zijn, moet voorlopig nog wel met vier verschillende formaten gewerkt worden. Elk font moet dus vier keer worden opgegeven. Gelukkig laadt elke browser allen het formaat waarmee die browser overweg kan. (Dit geldt ook voor Internet Explorer 8 en eerder.)

En ook gelukkig: goede zielen hebben precies uitgevogeld, hoe je die formaten op de juiste manier moet opgeven. En omdat geluk gratis is nog wat meer geluk: andere goede zielen hebben een @font-face kit generator geschreven, die niet alleen de benodigde css schrijft, maar ook de missende formaten bij een font aanmaakt. En nog gratis ook allemaal.

Dit moois is te vinden op fontsquirrel.com/fontface/generator. Je kiest 'n font, laadt dat in de generator en even later krijg je het font in vier formaten, bijbehorende css en demo-pagina retour. Da's nog 'ns wat anders dan de bonuskaart van Albert Heijn, want dit is écht gratis.

Deze generator is ook voor dit voorbeeld gebruikt, maar ik heb wel 'n paar aanpassingen in de css gemaakt, waardoor het wat makkelijker werkt. Dat wordt verder besproken in de Beschrijving van code en css.

(De code van deze generator is op zich prima, maar omdat hij automatisch wordt gegenereerd, is het niet de meest optimale code voor elke situatie.)

@font-face heeft een hele reeks eigenschappen, die (nog) niet door alle alle browsers worden ondersteund. Het is vrij lastig erachter te komen wat wel en niet wordt ondersteund.

font-style en font-weight worden door alle browsers ondersteund. font-variant, font-stretch, font-feature-setting en unicode-range worden nog niet of weinig ondersteund. Meer hierover kun je vinden bij font-weight: normal; font-style: normal; in de Beschrijving van code en css.

Beschrijving van code en css

	div#header-buiten
	{
	    position: absolute;
	    right: 16px;
	    width: 100%;
	    height: 120px;
	    background: yellow;
	}

	div#header-binnen
	{
	    margin-left: 16px;
	    height: 120px;
	    text-align: center;
	}

@font-face

Gewoon het begin van de regel. Eigenlijk vergelijkbaar met iets als div of h1 aan het begin van een css-regel. Maar omdat dit nou eenmaal niet geldt voor één of meer elementen en het beestje nou eenmaal een begin moet hebben, wordt begonnen met een @.

Zoals vaker het geval is bij css, is deze minder ingewikkeld, dan je mogelijk in eerste instantie zou denken. Bovendien kun je de css automatisch laten genereren op fontsquirrel. Deze regel is daar ook aangemaakt, hoewel hij daarna wel enigszins is aangepast.

In de toekomst wordt dit veel en veel eenvoudiger, want dan heb je nog maar één formaat nodig voor alle browsers. Nu zijn dat er nog vier.

font-family: 'Ubuntu Mono';

Hier wordt een naam gegeven aan het font. Dit is de naam, zoals die in de rest van de css wordt gebruikt in font-family als dit font moet worden aangeroepen. Precies zoals bij 'gewone' fonts dus. Je kunt elke naam geven die je wilt, al wil je het sinterklaas noemen. Ik heb gewoon de naam van het font gebruikt: Ubuntu Mono.

Omdat de naam uit twee woorden bestaat, gescheiden door een spatie, moet de naam tussen aanhalingstekens staan. (Ik gebruik bij @font-face trouwens altijd aanhalingstekens, omdat oudere versies van sommige browsers problemen schijnen te hebben als je hier geen aanhalingstekens gebruikt, ook als er geen spatie in de naam voorkomt.)

In de @font-face-regels hieronder geef ik nog fonts op voor cursief, vet en cursief én vet. Bij Ubuntu Mono worden voor deze drie stijlen drie aparte fonts gebruikt. In totaal worden er voor deze fontfamilie dus vier verschillende fonts gebruikt. Door alle vier de fonts dezelfde naam te geven ('Ubuntu Mono'), kan ik cursief, vet en cursief én vet op de normale manier aanroepen: door gewoon font-style en font-weight te gebruiken. Precies zoals bij 'gewone' fonts dus.

Ik kan ook het cursieve (of vette, of ...) font een eigen naam geven, bijvoorbeeld 'Ubuntu Mono Italic', maar dan moet ik het overal met die naam aanroepen als ik cursief wil hebben. Bovendien moet ik dan toch nog font-style: italic; gebruiken voor browsers die het webfont niet kennen, of voor als het webfont om een of andere reden niet wordt geladen, anders heb ik geen cursief.

De hele regel wordt dan bijvoorbeeld:

div {font-family: 'Ubuntu Mono Italic', font-style: italic;}

Door de fonts allemaal dezelfde naam te geven kan ik dit beperken tot:

div {font-style: italic;}

net zoals met 'normale' fonts.

src: url('098-fonts/ubuntumono-regular-webfont.eot');

src staat voor 'source': de bron. Hierachter staat de url, waar het font moet worden opgehaald. In dit geval is dat een relatief adres, omdat het in dezelfde map staat als de css. Maar als het webfont bijvoorbeeld bij Google vandaan komt, vul je hier het adres op de site van Google in.

In dit geval staat het font in de map '098-fonts'.

Het heet 'ubuntumono-regular-webfont.eot'. Dit is de naam die fontsquirrel aan het font heeft gegeven toen het font en de css werden gegenereerd, en daar ben ik verder afgebleven.

De extensie '.eot' geeft het formaat van het font aan.

Hier staat dus simpelweg: gebruik dit font als je Ubuntu Mono moet gebruiken (de naam Ubuntu Mono is helemaal in het begin van deze regel al opgegeven.)

Hier gelijk onder staat nog een src met veel meer fonts. Een browser kijkt eerst naar de onderste src, dan naar die daarboven, enz. In de onderste src staan de fonts voor versies van Internet Explorer ouder dan versie 9. In die browsers zit - uiteraard - een bug. De onderste src is aan die bug aangepast.

Internet Explorer 9 heeft de mogelijkheid om een site weer te geven in de zogenaamde compatibiliteitsweergave (onthouden voor Scrabble). De site wordt dan weergegeven alsof je hem bekijkt in Internet Explorer 7 of 8. Dat is gedaan om sites die (foutief) zijn aangepast voor die twee browsers toch goed weer te kunnen geven.

Maar die compatibiliteitsweergave is niet exact hetzelfde als de échte Internet Explorer 7 en 8. Er zijn bijvoorbeeld wat bugs uitgehaald. Zoals de bug met betrekking tot @font-face. Met als gevolgd dat Internet Explorer 9 in compatibiliteitsweergave @font-face zou negeren. Dat wordt door deze extra regel voorkomen.

Internet Explorer 9 in compatibiliteitsweergave leest de onderste src, verslikt zich, gaat door met de daarboven staande src - dat is dus deze dus -, verslikt zich niet en gebruikt keurig het hier opgegeven webfont.

(Als ik ooit de $(#%*% in m'n handen krijg die 'compatibiliteitsweergave' heeft bedacht. Heeft vast aandelen in de RSI-bestrijding. Vermoedelijk naaste familie van de bedenker van 'specificiteit', ook zo'n fijne om te typen.)

src: local('Ubuntu'), url('098-fonts/ubuntumono-regular-webfont.eot?#iefix') format('embedded-opentype'), url('098-fonts/ubuntumono-regular-webfont.woff') format('woff'), url('098-fonts/ubuntumono-regular-webfont.ttf') format('truetype'), url('098-fonts/ubuntumono-regular-webfont.svg#UbuntuMonoRegular') format('svg');

Als je dit stukje voor stukje bekijkt, is het minder ingewikkeld dan het lijkt.

Dit is de tweede src in deze regel. Normaal genomen is één src genoeg, maar vanwege de technische hoogstandjes van Microsoft in het verleden was de hierboven staande src ook nodig om problemen in Internet Explorer te voorkomen. Waarmee dit dus de tweede src is.

src: local('Ubuntu'),

Deze src begint niet met een webfont dat vanaf internet moet worden gedownload, maar kijkt eerst of het font misschien al aanwezig is in de computer. Dat gaat natuurlijk veel sneller, dan wanneer het moet worden gedownload.

Normaal genomen zal het font niet al aanwezig zijn, omdat je normaal genomen als webfont toch een ietwat apart font zult gebruiken, wat juist niet al aanwezig is op de meeste computers. In dit geval weet ik echter dat op mijn Linux-computer dit font al is geïnstalleerd.

Met local('Ubuntu') geef ik aan dat eerst gekeken moet worden of er al een font met de naam 'Ubuntu' aanwezig is. Als dat zo is, wordt er geen font gedownload. Op mijn Windows-computer is dat font niet aanwezig en wordt het dus wel gedownload.

De naam van het font moet exact hetzelfde zijn als de naam van het geïnstalleerde font. Dat is niet de naam van het bestand, maar de naam die de ontwerper aan het font heeft gegeven. Die naam is te vinden door het font in een font-manager of zoiets te openen.

Je kunt meerdere lokale namen proberen. Er zitten soms kleine afwijkingen tussen bijvoorbeeld OSX en Windows in de naamgeving, dus dat kan handig zijn. Dat doe je gewoon zo:

local('Ubuntu Italic'), local('Ubuntu-Italic'), ...

Internet Explorer 7 en 8 kijken alleen naar het eerste lokale font en negeren eventuele volgende lokale fonts.

url('098-fonts/ubuntumono-regular-webfont.eot?#iefix') format('embedded-opentype'),

Het eerste echte webfont. Achter de url staat het adres waar dit webfont moet worden opgehaald. In dit geval is het adres relatief, omdat de fonts in dezelfde map staan als de css. Maar als het font bijvoorbeeld bij Google vandaar moet komen, vul je hier het adres op de site van Google in.

Dit font is in het formaat eot. Dit formaat wordt gebruikt door Internet Explorer ouder dan versie 9. Ook Internet Explorer 9 kan ermee overweg, maar die kan ook met het nieuwere .woff overweg, zoals (binnenkort) alle fatsoenlijke browsers.

Achter de naam van het font staat een vraagteken. Dit is de zogenaamde 'iefix'. Internet Explorer 7 en 8 stoppen met lezen na dat vraagteken, omdat de sukkels denken dat de regel hier eindigt. Hoewel, sukkels... Als ze dat niet zouden doen, zouden ze zich verslikken in de rest. Als er meer dan één formaat font wordt opgegeven, werkt @font-face niet in Internet Explorer 7 en 8.

Deze slimme oplossing is bedacht door een groep mensen die gelukkig niet waren besmet met het patent-virus, maar in onderlinge samenwerking deze regel steeds verder hebben verbeterd. Links naar de sites van deze mensen staan onder Opmerkingen en op de pagina met links onder CSS → Fonts.

Internet Explorer 7 en 8 stoppen dus gewoon met lezen hier, de rest van de browsers gaat vrolijk door met lezen. Dat is maar goed ook, want alleen Internet Explorer kan met het format .eot uit de voeten.

De toevoeging #iefix is niet nodig, maar is door de generator van de css toegevoegd. Ik laat het staan, zodat ik over 37 jaar ook nog weet waarom dat rare vraagteken er staat.

(Omdat Internet Explorer 9 in compatibiliteitsweergave wél verder leest na het vraagteken, die bug is gerepareerd, ziet die meer fonts staan. En gebruikt er dus geen een, want díé bug is niet gerepareerd door Microsoft. Zucht. Daarom staat hierboven een aparte src-regel voor Internet Explorer 9 in compatibiliteitsweergave.)

Helemaal aan het eind staat een zogenaamde hint: format('embedded-opentype'). Normale browsers (dus niet Internet Explorer 7 en 8) kijken hiernaar om te zien, of ze iets met dit font kunnen. Als de browser niets kan met dit formaat, downloadt hij dit font niet, maar kijkt bij het volgende formaat. En dat is dan gelijk het volgende stukje in deze regel:

url('098-fonts/ubuntumono-regular-webfont.woff') format('woff'),

Deze regel is precies hetzelfde als die hierboven, alleen heeft het font een andere extensie: woff. Met dit formaat kunnen onder andere Internet Explorer 9 en 10, Firefox, Google Chrome, Safari, Opera, Safari op iOS en Opera Mobile uit de voeten.

De fix voor Internet Explorer 7 en 8 mist hier, want die zijn hierboven bij het vraagteken al gestopt met lezen.

De hint is ook anders, want het gaat hier om een ander formaat.

url('098-fonts/ubuntumono-regular-webfont.ttf') format('truetype'),

Precies hetzelfde als de regel hierboven, maar met weer een ander formaat. Dit formaat is geschikt voor Firefox, Google Chrome, Safari, Safari op iOS, Opera Mobile en Android.

url('098-fonts/ubuntumono-regular-webfont.svg#UbuntuMonoRegular') format('svg');

Precies hetzelfde als de regel hierboven, maar met weer een ander formaat. Dit formaat is geschikt voor oudere versies van Opera, Google Chrome, Safari en iOS.

Omdat dit formaat minder efficiënt wordt weergegeven dan truetype, kan dit formaat beter na truetype staan. Als bijvoorbeeld een nieuwere versie van iOS het truetype-formaat tegenkomt, wordt niet verder gezocht en het svg-formaat dus niet gebruikt.

De # in de naam is nodig, omdat dit type formaat een id nodig heeft om aangeroepen te kunnen worden. Die id staat achter de #.

font-weight: normal; font-style: normal;

Hiermee geef ik aan dat de in deze zelfde regel opgegeven bestanden gebruikt moeten worden, als een normaal niet-vet, niet-cursief teken in dit font moet worden weergegeven. Met 'dit font' bedoel ik het font Ubuntu Mono, want die naam heb ik het helemaal aan het begin van deze regel gegeven.

Ik geef in deze zelfde regel dus eerst de naam aan het font, dan geef ik de bestandsnamen van het te gebruiken font op, en ten slotte gewicht en stijl van het font.

Omdat dit allemaal in dezelfde regel staat, zijn deze fonts - waarin de gewone, normale tekens staan - gekoppeld aan de naam Ubuntu Mono met een normale font-weight en een normale font-style.

Bij Ubuntu Mono worden speciaal ontworpen fonts gebruikt voor cursief (italic), vet (bold) en vet-cursief (bolditalic). De opbouw van de @font-face-regels voor deze speciale fonts is precies hetzelfde als die voor de normale tekens.

Alle drie de varianten krijgen dezelfde naam als het font voor de gewone tekens: 'Ubuntu Mono'.

Maar als bestandsnaam van de te gebruiken fonts geef ik nu de namen van het cursieve, het vette of het vet-cursieve font op.

Bij font-weight en font-style geef ik het gewicht en de stijl op, waarvoor deze variant van het font gebruikt moet worden.

Voor cursief is dat font-weight: normal; font-style: italic;

Voor vet is het font-weight: bold; font-style: normal;

En voor vet-cursief font-weight: bold; font-style: italic;

Bij font-weight zijn de waarden normal, bold en 100 tot en met 900 toegestaan.

Bij font-style zijn de waarden normal, italic en oblique toegestaan.

Omdat ook voor deze drie varianten de naam van het font, de naam van de bijbehorende bestanden en het gewicht en de stijl in dezelfde regel staan, zijn de varianten gekoppeld aan de naam Ubuntu Mono en het juiste bestand voor de juiste variant.

Hierdoor ontstaat een echte 'font-familie' onder de naam Ubuntu Mono met een normale, een cursieve, een vette en een vet-cursieve variant. Omdat ze allemaal onderdeel van Ubuntu Mono zijn, hoef ik voor de cursieve stijl alleen maar het gebruikelijke font-style: italic; op te geven, en niet elke keer iets als font-family: 'Ubuntu Mono Italic'; font-style: italic;.

(Ik moet natuurlijk wel eerst op geven dat Ubuntu Mono moet worden gebruikt in bijvoorbeeld een div. Maar bínnen die div kan ik dan volstaan met het op de normale manier opgeven van cursief of vet, zonder een aparte fontnaam te hoeven gebruiken.)

Bijkomend voordeel is ook nog dat, als om een of andere reden het webfont niet wordt gedownload, er toch cursieve of vette tekst verschijnt, omdat de gewone, normale standaard-css wordt gebruikt, die elk font begrijpt.

Als font-weight en/of font-style niet goed worden opgegeven in de @font-face-regel voor de verschillende varianten, kun je vreemde resultaten krijgen. Op de afbeelding geeft Firefox op Linux twee vet-cursieve letters dubbelvet respectievelijk dubbel-cursief weer als gevolg van verkeerd opgegeven waarden.

(En nee, je kunt dit niet gebruiken om zelf exotische resultaten te produceren. Los van dat dit een duidelijk geval voor de Raad voor de Typografen-mishandeling zou zijn, geven verschillende browsers en verschillende besturingssystemen verschillende afwijkingen.)

Als ik elke variant van het font een eigen naam geef, dus bijvoorbeeld 'Ubuntu Mono Italic' in plaats van 'Ubuntu Mono', moet ik die naam elke keer als ik cursief wil gebruiken volledig opgeven met font-family: 'Ubuntu Mono Italic'; Erger nog: ik moet ook fallback-fonts opgeven voor het geval het webfont niet wordt geladen, en om diezelfde reden ook de fontstijl.

Als ik bovenstaande methode niet gebruik, moet ik dus elke keer als ik cursief (of vet, of ...) wil gebruiken opgeven:

font-family: 'Ubuntu Mono Italic', Arial, Helvetica, sans-serif, font-style: italic;

Wat nogal iets meer is dan alleen font-style: italic;

De code die de generator op fontsquirrel aanmaakt, zet in de css standaard font-style: normal; font-weight: normal;. Als je aparte fonts gebruikt voor cursief en dergelijke, moet je dit dus zelf even aanpassen.

Naast font-weight en font-style zijn er nog wat eigenschappen mogelijk bij @font-face. Het gaat hier om de mogelijkheden in combinatie met @font-face, niet om het normale gebruik van deze eigenschappen. Ze worden op dezelfde manier als font-weight en font-style gebruikt. Ik heb deze eigenschappen, om verschillende redenen, niet gebruikt. Het gaat om de volgende eigenschappen:

font-variant: In css3 worden de mogelijke waarden bij deze eigenschap enorm uitgebreid, maar veel is daar nog niet over te vinden. Alleen Safari ondersteunt het, en dan alleen de waarden normal en small-caps. Althans: elders op de site van Safari staat dat, bij webfonts, alleen de waarde normal wordt ondersteund. Tja.

font-stretch wordt alleen ondersteund door Internet Explorer 9. Het wordt gebruikt om een font breder ('expanded') of smaller ('condensed') weer te geven en werkt alleen echt goed als een speciaal voor deze weergave ontworpen font wordt gebruikt.

font-feature-settings wordt alleen door Firefox ondersteund met het voorvoegsel -moz- en is nog hevig in ontwikkeling. Je kunt er dingen als het wel of niet gebruiken van ligaturen en dergelijke in bepaalde soorten fonts mee regelen. (Een ligatuur is iets als æ.)

unicode-range wordt alleen ondersteund door Internet Explorer 9. Het geeft de mogelijkheid om aan te geven dat voor bepaalde (reeksen) tekens een bepaald font moet worden gebruikt. In principe wordt dit font alleen gedownload, als op de pagina deze tekens voorkomen. Maar ook hier geldt: het is nog hevig in ontwikkeling.

Dit moet niet worden verward met het verkleinen van het aantal in het font aanwezige tekens. Fontsquirrel bijvoorbeeld biedt de mogelijkheid om het te downloaden font te beperken tot specifieke (series) tekens, waardoor het (veel) kleiner kan worden.

#ubuntu-content, #jinky-content

De elementen met id="ubuntu-content" en id="jinky-content". Dit zijn de twee divs waarin respectievelijk de fonts Ubuntu Mono en Jinky staan.

De meeste eigenschappen voor deze twee divs zijn hetzelfde, daarom geef ik ze hier in één keer op. Enkele afwijkende instellingen voor div#jinky-content geef ik later op bij #jinky-content.

width: 700px;

Breedte.

max-width: 100%;

Een breedte in procenten wordt altijd genomen ten opzichte van de ouder van het element. Als die er niet is, zoals hier het geval is, geldt de breedte ten opzichte van het venter van de browser. De maximumbreedte mag dus nooit meer worden dan 100% van de breedte van het venster van de browser. Hierdoor zal zelfs in heel smalle vensters of bij een heel grote letter geen horizontale scrollbalk verschijnen.

border: black solid 1px;

Randje rondom de divs. Omdat de divs tegen elkaar aan staan, komt de lijn aan de onderkant van de bovenste div tegen de lijn aan de bovenkant van de onderste div te staan. Dat levert als grens tussen de twee divs een iets dikkere lijn op, wat me hier goed uitkomt.

margin: 0 auto;

Omdat voor onder en links geen waarde is ingevuld, krijgen die automatisch dezelfde waarde als boven en rechts. Hier staat dus eigenlijk 0 auto 0 auto in de volgorde boven - rechts - onder - links.

Boven en onder geen marge, links en rechts auto. Dat betekent in dit geval evenveel oftewel: de divs staan altijd in het midden van het venster van de browser, ongeacht de breedte hiervan.

Deze manier van horizontaal centreren van een blok-element werkt alleen, als het te centreren element een breedte heeft.

padding: 5px 5px 10px;

Omdat voor links geen waarde is opgegeven, krijgt dat automatisch dezelfde waarde als rechts. Hier staat dus eigenlijk 5px 5px 10px 5px in de volgorde boven - rechts - onder - links. Kleine afstand tussen de tekst in de divs en de rand van de divs.

Aan de onderkant ietsje meer dan aan de andere kanten, omdat de 'g' in de onderste regel van de onderste div wel heel dichtbij de rand van de div komt, en dat ziet er niet goed uit.

color: black;

Tekstkleur zwart.

Voorgrondkleur zwart. Dit is onder andere de kleur van de tekst.

Hoewel dit de standaardkleur is, geef ik de kleur toch op. Hieronder geef ik een achtergrondkleur op. Sommige mensen hebben zelf de voorgrond- en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als ik nu de achtergrondkleur verander, maar niet de voorgrondkleur, loop ik het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

Door beide op te geven, weet ik redelijk zeker dat achtergrond- en tekstkleur genoeg van elkaar blijven verschillen. Als de gebruiker !important heeft gebruikt, is er nog niets aan de hand, want dan veranderen achtergrond- en voorgrondkleur geen van beide.

Ik heb dit ook al bij <body> opgegeven, maar sommige mensen hebben bij álle elementen de kleuren veranderd. Het heeft immers weinig zin als ze dat alleen bij de body doen, terwijl de sitebouwer de kleuren ook bij bijvoorbeeld de paragrafen heeft aangepast.

background: white;

Witte achtergrond.

font-family: 'Ubuntu Mono', Arial, Helvetica, sans-serif;

Gebruik een font met de naam Ubuntu Mono. Dit font is ter beschikking gekomen, omdat het - als alles goed is gegaan - wordt gedownload vanaf de bij @font-face opgegeven url.

Omdat verder geen variant als cursief of vet wordt opgegeven, wordt het gewone normale standaardfont gebruikt.

Het is altijd mogelijk dat, om wat voor reden dan ook, het webfont niet of niet goed wordt gedownload. Daarom worden ook alternatieve fonts opgegeven: Arial en Helvetica. Als het webfont niet beschikbaar is, wordt eerst Arial geprobeerd en daarna Helvetica. Die twee fonts bestrijken samen vrijwel alle computers.

Als ook die twee fonts niet beschikbaar zijn, mag de browser het helemaal zelf uitsoppen. Er wordt alleen nog één laatste zogenaamd generiek font opgegeven: sans-serif. Dat wil zeggen: schreefloos, zonder dwarsstreepjes, want dat leest op het scherm prettiger. Welk font maakt niet uit, als het maar schreefloos is.

Als het webfont niet kan worden gebruikt, om wat voor reden dan ook, kan zich 'n onverwacht probleem voordoen. Het alternatieve font zou iets kleiner of groter kunnen zijn. Dat een font in px of 'n andere eenheid dezelfde maat heeft, wil nog niet zeggen dat het op het scherm ook dezelfde maat heeft.

Als het font iets kleiner is, zal dat meestal niet veel problemen opleveren. Maar als het net iets groter is, kan je prachtige lay-out aardig in de vernieling raken.

Op de afbeelding hiernaast staat linksboven een letter uit het font 'Times New Roman'. Rechts en onder staat een letter uit het font 'Tlwg Typist'. Alle letters zijn 30 px groot. Je hoeft geen timmermansoog te hebben om te zien dat de Times New Roman veel breder en hoger is dan de andere. En dat daardoor hoogte en vooral breedte van 'n volledige zin in het ene font nogal zal verschillen van die in het andere font.

Het goede nieuws is dat er een eigenschap is, die precies dit probleem oplost: font-size-adjust. Je geeft van één font een bepaalde waarde op, en andere fonts worden dan in dezelfde grootte weergegeven.

Het slechte nieuws is dat dit alleen in Firefox werkt. En het is mij niet gelukt het daarin goed te laten werken. Dat kan aan mij liggen, maar ik denk eerlijk gezegd dat het ook in Firefox (nog) niet goed werkt.

Op dit moment is er maar één praktische oplossing: zorgen dat de vervangende fonts (ongeveer) even groot worden weergegeven. Ik heb daar op deze pagina niet op gelet, omdat het in dit geval helemaal niets uitmaakt hoe groot de letters precies worden weergegeven. Maar normaal genomen moet je hier grondig op testen.

font-size: 2em;

Beetje grote letter. Als eenheid neem ik em, zodat ook gebruikers van Internet Explorer de lettergrootte kunnen veranderen.

De code aanpassen aan je eigen ontwerp

• Als je dit voorbeeld gaat aanpassen voor je eigen site, houdt het dan in eerste instantie zo eenvoudig mogelijk. Ga vooral geen details invullen.

• Gebruik vooral geen FrontPage, Publisher of Word (alle drie van Microsoft). Deze programma's maken niet-standaard code, die alleen goed te bekijken is in Internet Explorer. In alle andere browsers zie je grotendeels bagger, áls je al iets ziet.

  Publisher en Word zijn niet bedoeld om websites mee te maken. FrontPage is zwaar verouderd en wordt niet meer onderhouden door Microsoft. Als je beslist iets van Microsoft wilt gebruiken, schaf dan (voor honderden euro's) een nieuwer programma aan, dat zich wel aan de standaarden houdt.

  Je kunt natuurlijk ook een goed gratis programma gebruiken. Links naar dat soort programma's vind je op de pagina met links onder Gereedschap wysiwyg-editor.

  Maar het allerbeste is om gewoon zelf html, css, enz. te leren, omdat zelfs het allerbeste programma het nog steeds zwaar verliest van 'n op de juiste manier met de hand gemaakte pagina.

• Als je 'n site maakt in Firefox, Opera, Safari, Google Chrome of Edge, is er 'n hele grote kans dat hij in alle browsers werkt. Ik geef de voorkeur aan Firefox, omdat het de enige grote browser is die niet bij een bedrijf hoort dat vooral op je centen of je data uit is.

  Google Chrome wordt ook door veel mensen gebruikt, maar ik heb dus wat moeite met hoe Google je hele surfgedrag, je schoenmaat en de kleur van je onderbroek vastlegt. Daarom gebruik ik Google Chrome zelf alleen om in te testen.

• Het allereerste dat je moet invoeren, is het doctype, vóór welke andere code dan ook. Een lay-out met een missend of onvolledig doctype ziet er totaal anders uit dan een lay-out met een geldig doctype. Wát er anders is, verschilt ook nog 'ns tussen de diverse browsers. Als je klaar bent en dan nog 'ns 'n doctype gaat invoeren, weet je vrijwel zeker dat je van voren af aan kunt beginnen met de lay-out.

  Geldige doctypes vind je op www.w3.org/QA/2002/04/valid-dtd-list.html.

  Gebruik het volledige doctype, inclusief de url, anders werkt het niet goed.

• Gebruik een 'strict' doctype of het doctype voor html5. Deze zijn bedoeld voor nieuwe sites. Het transitional doctype is bedoeld voor al bestaande sites, niet voor nieuwe. Het transitional doctype staat talloze tags toe, die in html5 zijn verboden. Deze tags worden al zo'n tien jaar afgeraden. Het transitional doctype is echt alleen bedoeld om de puinhoop van vroeger, toen niet volgens standaarden werd gewerkt, enigszins te herstellen.

  Het strict doctype staat verouderde tags niet toe. Daardoor kan met 'n strict doctype, of het nu html of xhtml is, probleemloos worden overgestapt naar html5. Met een transitional doctype en het gebruik van afgekeurde tags kun je niet overstappen naar html5. Je moet dan eerst alle verouderde tags verwijderen, wat echt ontzettend veel werk kan zijn.

• Als tweede voer je de charset in. Het beste kun je utf-8 nemen. Als je later van charset verandert, loop je 'n grote kans, dat je alle aparte tekens als letters met accenten weer opnieuw moet gaan invoeren.
• Test vanaf het allereerste begin in zoveel mogelijk verschillende browsers in 'n aantal resoluties (schermgroottes). Onder het kopje Getest in kun je in deze uitleg vinden waar ikzelf op test. Ook van Internet Explorer kun je meerdere versies naast elkaar draaien. Je kunt daarvoor zoeken op internet en op de pagina met links staan onder de kopjes Gereedschap → Meerdere versies van Internet Explorer draaien en Gereedschap → Weergave testen 'n aantal links, die daar ook bij kunnen helpen.
• Voor alle voorbeelden geldt: breng veranderingen stapsgewijs aan. Als je bijvoorbeeld foto's wilt laten weergeven, begin dan alleen met het veranderen van de namen van de foto's, zodat je eigen foto's worden weergegeven. Maakt niet uit als de maten niet kloppen en de teksten fout zijn. Als dat werkt, ga dan bijvoorbeeld de maten aanpassen. Dan de teksten. En controleer steeds, of alles nog goed werkt.

• Als het om een lay-out of iets dergelijks gaat: zorg eerst dat header, kolommen, footer, menu, en dergelijke staan en bewegen zoals je wilt, en ga dan pas details binnen die blokken invullen. In eerste instantie gebruik je dus bijvoorbeeld 'n leeg blok voor waar uiteindelijk het menu komt te staan.

  Als je begint met allerlei details, is er 'n heel grote kans dat die de werking van de blokken gaan verstoren. Bouw eerst het huis, en ga dan pas de kamers inrichten. Als de blokken eenmaal werken zoals je wilt, zul je het gelijk merken als 'n toegevoegd detail als tekst of 'n afbeelding iets gaat storen. Daarvoor moet je natuurlijk wel regelmatig controleren in verschillende browsers, of alles nog wel goed werkt.

  Je kunt de blokken tijdens het aanpassen opvullen met bijvoorbeeld <br>1<br>2<br>3 enz., tot ze de juiste hoogte hebben. Het is handig om aan het einde even iets toe te voegen als 'laatste', zodat je zeker weet dat er niet drie regels onderaan naar 't virtuele walhalla zijn verhuisd.

  Om de breedte te vullen kun je het best 'n kort woord als 'huis' duizend keer of zo herhalen. Ook hier is het handig om aan 't einde (en hier ook aan 't begin) 'n herkenningsteken te maken, zodat je zeker weet dat je de hele tekst ziet.

• Zolang je in grotere dingen zoals 'n lay-out aan 't wijzigen bent, zou ik je aanraden de verschillende delen een achtergrondkleur te geven. Je ziet dan goed, waar 'n deel precies staat.
• Als je instellingen verandert in de style, verander er dan maar één, hooguit twee tegelijk. Als je er zeventien tegelijk verandert, moet je niet verbaasd zijn, als je niet weet wat er is gebeurd. En als je 't niet meer terug kunt draaien.
• Marges, padding en border worden bij de hoogte en breedte van de inhoud opgeteld. Hier worden vaak fouten mee gemaakt. Als je bijvoorbeeld in een lay-out 'n border toevoegt aan een van de 'hoofdvakken' (header, footer, kolommen), dan wordt deze er dus bij opgeteld. Bij 'n border van 2 px rondom de linkerkolom wordt deze dus plotseling 4 px breder (2 aan beide kanten), en 4 px hoger. Zoiets kan je hele lay-out verstoren, omdat iets net te breed of te hoog wordt. Je moet dan elders iets 4 px kleiner maken. Dat zal vaak zo zijn: als je één maat verandert, zul je vaak ook 'n andere moeten aanpassen.
• In plaats van px kun je ook andere maten gebruiken, met name em. Voordeel van em is dat het door de gebruiker kan worden vergroot en verkleind, ook in Internet Explorer (andere browsers hebben meer mogelijkheden op dit gebied). Nadeel is dat het de lay-out sneller kan verstoren dan bijvoorbeeld px. Dit moet je gewoon van geval tot geval bekijken.

• Valideren, valideren, valideren en dan voor 't slapen gaan nog 'ns valideren.

  Valiwie???

  Valideren is het controleren van je (x)html en css op 'n hele serie fouten. Computers zijn daar vaak veel beter in dan mensen. Als je 300 keer <h2> hebt gebruikt en 299 keer </h2> vindt 'n computer die ene missende </h2> zonder enig probleem. Jij ook wel, maar daarna ben je misschien wel aan vakantie toe.

  Je kunt je css en (x)html zowel valideren als 't online staat, als wanneer 't nog in je computer staat.

  (x)html kun je valideren op: validator.w3.org

  css kun je valideren op: jigsaw.w3.org/css-validator

  Valideren kan helpen om gekmakende fouten te vinden. Valid code garandeert ook, dat de weergave in verschillende browsers (vrijwel) hetzelfde is. En valid code is over twintig jaar ook nog te bekijken.

Toegankelijkheid en zoekmachines

Het eerste deel van deze tekst is voor alle voorbeelden hetzelfde. Eventueel specifiek voor dit voorbeeld geldende dingen staan verderop onder het kopje Specifiek voor dit voorbeeld.

Toegankelijkheid (accessibility in het Engels) is belangrijk voor bijvoorbeeld blinden die een spraakbrowser gebruiken, of voor motorisch gehandicapte mensen die moeite hebben met het bedienen van een muis. Een spider van een zoekmachine (dat is het programmaatje wat de site indexeert voor de zoekmachine) is te vergelijken met een blinde. Als je je site goed toegankelijk maakt voor gehandicapten, is dat dus gelijk goed voor een hogere plaats in een zoekmachine. Dus als je 't niet uit sociale motieven wilt doen, kun je 't uit egoïstische motieven doen.

(Op die plaats in de zoekmachine heb je maar beperkt invloed. De toegankelijkheid van je site is maar één van de factoren, maar zeker niet onbelangrijk.)

Als je bij het maken van je site al rekening houdt met toegankelijkheid, is dat nauwelijks extra werk. 't Is ongeveer te vergelijken met inbraakbescherming: doe dat bij 'n nieuw huis en 't is nauwelijks extra werk, doe 't bij 'n bestaand huis en 't is al snel 'n enorme klus.

Enkele tips die helpen bij toegankelijkheid:

• Gebruik altijd een alt-beschrijving bij een afbeelding. De alt-tekst is wat wordt gebruikt, als afbeeldingen niet kunnen worden gezien (dat geldt dus ook voor zoekmachines). Als je iets wilt laten zien als je over de afbeelding hovert, gebruik daar dan het title-attribuut voor, niet de alt-beschrijving.
• Gebruik bij een link een title, waarin je omschrijft waar de link naar toe leidt.

• Accesskeys (sneltoetsen) kun je beter niet gebruiken. Deze gaven te veel problemen, omdat ze vaak dubbelop zijn met sneltoetsen voor de browser of andere al gebruikte sneltoetsen. Bovendien is voor de gebruiker meestal niet duidelijk, welke toetsen het zijn.

  In de komende html5 waren ze eerst niet toegestaan, maar inmiddels lijkt het erop dat ze toch worden toegestaan, maar op 'n andere manier dan in html 4.01. Ik ga ze zelf pas weer gebruiken, als duidelijk is hoe ze gaan werken, en als ze beter zijn uitgedacht dan in html 4.01 het geval was, want bij een goede toepassing is het op zich een heel goed idee.

• Met behulp van de Tab-toets (of op 'n soortgelijke manier) kun je in de meeste browsers door de links lopen. Elke tab brengt je één link verder, Shift+Tab één link terug. Met behulp van tabindex kun je de volgorde aangeven waarin de Tab-toets werkt. Zonder tabindex wordt de volgorde van de code aangehouden, maar soms is een andere volgorde logischer.

• In het verleden werd vaak aangeraden de volgorde van de code aan te passen. Een menu bijvoorbeeld kon in de html onderaan worden gezet, terwijl het op het scherm met behulp van css bovenaan werd gezet. Inmiddels zijn screenreaders en dergelijke zo verbeterd, dat dit niet meer wordt aangeraden. De volgorde in de html kan tegenwoordig beter hetzelfde zijn als op het scherm, omdat het anders juist verwarrend kan werken.

  Een andere mogelijkheid is een zogenaamde skip-link: een link die je buiten het scherm parkeert met behulp van css, zodat hij normaal genomen niet te zien is. Zo'n link is wel zichtbaar te maken in speciale programma's zoals spraakbrowsers. Die link staat boven menu, header, en dergelijke, en linkt naar de inhoud van de pagina, zodat mensen met één klik het hele menu kunnen passeren.

• Van oorsprong was html een taal om wetenschappelijke documenten weer te geven, pas later is hij gebruikt voor lay-out. Maar daar is hij dus eigenlijk nooit voor bedoeld geweest. Het gebruiken van html voor lay-out leidt tot enorme problemen voor gehandicapten en tot een lage plaats in zoekmachines.

  De html hoort alleen inhoud te bevatten, lay-out doe je met behulp van css. Die css moet in een extern stylesheet staan of, als hij alleen voor één bepaalde pagina van toepassing is, in de head van die pagina. Zoekmachines zijn ook niet dol op een oerwoud van inline-stijlen (dat zijn stijlen in de tag zelf: <div style="...">.)

• Breng een logische structuur aan in je document. Gebruik een <h1>voor de belangrijkste kop, een <h2> voor een subkop, enz. Spraakbrowsers en dergelijke kunnen van kopregel naar kopregel springen. En een zoekmachine gaat ervan uit dat <h1> belangrijke tekst bevat.

  Dit geldt voor al dit soort structuurbepalende tags.

  Als een <h1> te grote letters geeft, maak daar dan met behulp van je css 'n kleinere letter van, maar blijf die <h1> gewoon gebruiken. Op dezelfde manier kun je al dit soort dingen oplossen.

• Een table is fantastisch, maar alleen als die wordt gebruikt om een echte tabel weer te geven, niet als hij voor opmaak wordt misbruikt. In het verleden is dat op grote schaal gebeurd bij gebrek aan andere mogelijkheden. Een tabel is, als je niet heel erg goed oplet, volstrekt ontoegankelijk voor gehandicapten en zoekmachines. Het lezen van een tabel is ongeveer te vergelijken met het lezen van een krant van links naar rechts: niet per kolom, maar per regel. Dat gaat dus alleen maar goed bij een echte tabel zoals een spreadsheet. In alle andere gevallen garandeert 'n tabel 'n lagere plaats in een zoekmachine.

• Frames zijn een volstrekt verouderde techniek, die heel veel nadelen met zich meebrengt. <iframe>'s hebben voor een deel dezelfde nadelen. Eén van die nadelen is dat de verschillende frames voor zoekmachines, schermlezers, en dergelijke als los zand aan elkaar hangen, omdat ze los van elkaar worden weergegeven. Ze staan wel naast elkaar op het scherm, maar er zit geen verband tussen.

  Als je 'n stuk code vaker wilt gebruiken, zoals 'n menu dat op elke pagina hetzelfde is, voeg dat dan in met PHP of SSI. Dan wordt de pagina niet in de browser, maar al op de server samengesteld. Hierdoor zien zoekmachines, schermlezers, en dergelijke één pagina, net zoals wanneer je maar één pagina met html zou hebben geschreven.

• Geef de taal van het document aan, en bij woorden en dergelijke die afwijken van die taal de afwijkende taal met behulp van lang="..". Ik doe dat op mijn eigen site maar af en toe, omdat de tekst (en vooral de code) een mengsel is van Engels, Nederlands en eigengemaakte namen. Dit soort teksten is gewoon niet goed in te delen in een taal.
• Gebruik de tag <abbr> bij afkortingen. Doe dat de eerste keer op een pagina samen met de title-eigenschap: <abbr title="en dergelijke">e.d.</abbr>. Daarna kun je op dezelfde pagina volstaan met <abbr>e.d.</abbr>. Doe je dit niet, dan is er 'n grote kans dat 'n spraakbrowser e.d. uit gaat spreken als Ed, en 'n zoekmachine kan er ook geen chocola van maken.

• De spider van 'n zoekmachine, spraakbrowsers, en dergelijke kunnen geen plaatjes 'lezen'. Het is soms verbazingwekkend om te zien hoe veel, of eigenlijk: hoe weinig tekst er overblijft op een pagina als de plaatjes worden weggehaald. Hetzelfde geldt voor die fantastisch mooie flash-pagina's, als daarbij geen voorzieningen voor dit soort programma's zijn aangebracht.

  Op Linux kun je met Lynx kijken hoe je pagina eruitziet zonder plaatjes en dergelijke, als echt alleen de tekst overblijft. Een installatie-programma voor Lynx op Windows is te vinden op csant.info/lynx.

  In Windows kun je ook het gratis programma WebbIE installeren. WebbIE laat de pagina zien, zoals een spraakbrowser en dergelijke hem zien. WebbIE is te downloaden vanaf www.webbie.org.uk.

  Ten slotte kun je je pagina nog online laten controleren op 'n behoorlijk aantal sites. Ik noem er hier enkele. Helaas zijn ze bijna allemaal Engelstalig.

  wave.webaim.org Deze laat grafisch zien hoe de toegankelijkheid is. Heel erg duidelijk, maar bij grotere pagina's wordt 't al snel erg chaotisch.

Specifiek voor dit voorbeeld

Als het webfont om wat voor reden dan ook niet werkt, tonen alle browsers de tekst in een wel beschikbaar font. Het webfont wordt alleen gebruikt voor het uiterlijk, erachter zit volkomen normale tekst. Het gebruik van webfonts levert dan ook geen enkel probleem op voor spraakbrowsers en dergelijke.

Getest in

Laatst gecontroleerd op 7 augustus 2012.

Onder dit kopje staat alleen maar, hoe en waarin is getest. Eventuele problemen, ook die met betrekking tot zoomen en lettergroottes, staan hieronder bij Bekende problemen. Het is belangrijk dat te lezen, want uit een test kan ook prima blijken dat iets totaal niet werkt!

Eventuele opmerkingen over de toegankelijkheid specifiek voor dit voorbeeld staan onderaan Toegankelijkheid en zoekmachines onder het kopje Specifiek voor dit voorbeeld.

Dit voorbeeld is getest op de volgende systemen:

• Windows XP:
  Firefox, Opera, Safari en Google Chrome in een resolutie van 1440x900.
  Internet Explorer 8 in de resoluties 800x600, 1024x768, 1280x1024 en 1440x900.
  Internet Explorer 7 in de resoluties 800x600, 1024x768 en 1280x1024.
• Windows 7:
  Firefox, Opera, Safari, Google Chrome en Internet Explorer 9 in de resoluties 800x600, 1024x768 en 1280x1024.
• OS X:
  Firefox, Opera, Safari en Google Chrome in de resolutie 1024x768.
• Linux:
  Firefox, Opera en Google Chrome in de resoluties 800x600, 1024x768 en 1280x1024.
• iPad met iOS 5.1.1 in een resolutie van 1024x768 (MC979NF):
  Safari (portret en landschap).
  Opera Mini (portret en landschap).
  Chrome for IOS (portret en landschap).
• Android 4.0.3 in een resolutie van 1024x768 (CRESTA CTP888):
  Android browser, Opera Mobile, Firefox en Chrome voor mobiel (alles portret en landschap).
• Android 2.3.6 in een resolutie van 320x240 (Samsung Galaxy Y GT-S5360):
  Android browser (portret en landschap).
  Opera Mobile (éénkolomsstand aan/uit, portret en landschap).
  Opera Mini (éénkolomsstand aan/uit, portret en landschap). Deze browser is een apart geval. De opgevraagde site wordt gedownload via de servers van Opera, waarbij het in zo'n klein venster normaal is dat (het grootste deel van) de lay-out wordt verwijderd. Daarom wordt bij deze browser alleen gekeken, of er geen content (tekst en dergelijke) verloren gaat.

Er is steeds getest met de laatste versie van de browsers op de hierboven genoemde controledatum, omdat ik geen zin heb om rekening te houden met mensen die met zwaar verouderde browsers surfen. Dat is trouwens vragen om ellende, want updates van browsers hebben heel vaak met beveiligingsproblemen te maken.

In resoluties groter dan 800x600 is ook in- en uitzoomen en - voor zover de browser dat kan - een kleinere en grotere letter getest. Er is ingezoomd en vergroot tot zover de browser kan, maar niet verder dan tot 200%.

Er is getest met behulp van muis en toetsenbord, behalve op de iPad en Android, waar een touchscreen is gebruikt.

Naast deze 'gewone' browsers is ook getest in Lynx, WebbIE, NVDA en Fangs Screen Reader Emulator. Lynx is een browser die alleen tekst laat zien en geen css gebruikt. WebbIE is een browser die gericht is op mensen met een handicap. NVDA is een screenreader, zoals die door blinden wordt gebruikt. Fangs Screen Reader Emulator is een extensie bij Firefox, die de pagina laat zien, zoals een screenreader hem ziet.

Als het voorbeeld in deze vier programma's toegankelijk is, zou het in principe toegankelijk moeten zijn in alle aangepaste browsers en dergelijke. En dus ook voor zoekmachines, want een zoekmachine is redelijk vergelijkbaar met een blinde. Eventuele opmerkingen over de toegankelijkheid specifiek voor dit voorbeeld staan onderaan Toegankelijkheid en zoekmachines onder het kopje Specifiek voor dit voorbeeld.

Alleen op de hierboven genoemde systemen en browsers is getest. Er is dus niet getest op bijvoorbeeld 'n Blackberry. De kans is (heel erg) groot dat dit voorbeeld niet (volledig) werkt op niet-geteste systemen en apparaten. Om het wel (volledig) werkend te krijgen, zul je vaak (kleine) wijzigingen en/of (kleine) aanvullingen moeten aanbrengen, bijvoorbeeld met JavaScript.

Er is ook geen enkele garantie dat iets werkt in een andere tablet of smartphone dan hierboven genoemd, omdat fabrikanten in principe de software kunnen veranderen. Dit is anders dan op de desktop, waar browsers altijd (vrijwel) hetzelfde werken, zelfs op verschillende besturingssystemen. Iets wat in Android browser werkt, zal in de regel overal werken in die browser, maar een garantie is er niet. De enige garantie is het daadwerkelijk testen op een fysiek apparaat. En aangezien er duizenden mobiele apparaten zijn, is daar eigenlijk geen beginnen aan.

De html is gevalideerd met de validator van w3c, de css ook. Als om een of andere reden niet volledig gevalideerd kon worden, wordt dat bij Bekende problemen vermeld.

Nieuwe browsers test ik pas, als ze uit het bèta-stadium zijn, omdat er anders 'n redelijke kans is dat ik 'n bug zit te omzeilen, die voor de uiteindelijke versie nog gerepareerd wordt. Dit voorbeeld is alleen getest in de hierboven met name genoemde browsers. Vragen over niet-geteste browsers kan ik niet beantwoorden, en het melden van fouten in niet-geteste browsers heeft ook geen enkel nut. (Melden van fouten, problemen, enz. in wel geteste browsers: graag!)

Bekende problemen

Waarop en hoe is getest, kun je gelijk hierboven vinden bij Getest in.

Opera Mini op Android 2.3.6

Opera kent @font-face niet en geeft dus alles in een standaardfont weer, Ubuntu Mono én Jinky. Bovendien wordt cursieve tekst gewoon rechtopstaand weergegeven.

Opera Mini op IOS

Opera kent @font-face niet en geeft dus alles in een standaardfont weer, Ubuntu Mono én Jinky. Cursief en vet worden wel goed weergegeven.

Android browser op Android 2.3.6

In deze versie van Android browser zit een kanjer van een bug. Bij Ubuntu Mono wordt als een van de eerste bronnen met local een lokale bron opgegeven. Als het font toevallig al in de computer aanwezig is, hoeft het niet te worden gedownload. Maar door het gebruik van local werkt @font-face niet meer in Android browser en wordt altijd een standaardfont gebruikt. Bij Jinky wordt local niet gebruikt, en dat werkt dan ook wel goed in Android browser.

In Android 4 is deze bug verholpen, daar werkt het zoals het hoort te werken. Maar op dit moment heb je daar nog weinig aan, want Android 2 is nog verreweg de meest gebruikte versie.

Je kunt local gebruiken onder het motto 'wat niet weet, wat niet deert', en 'ach, eigenlijk wel prima, want dat downloaden duurt toch te lang voor 'n mobiel gebeuren'. De andere mogelijkheid is om de lokale bron weg te laten, waardoor het font dus áltijd wordt gedownload, ook als het eventueel al geïnstalleerd zou zijn. Vaak zal dat trouwens niet het geval zijn, dus het weglaten van local zal niet echt 'n probleem opleveren.

Als je local wilt weglaten, moet je gewoon local('...'), weglaten. De rest van de regel blijft het zelfde. Op de plaats van de puntjes staat de naam van het font, hier is dat 'Ubuntu', 'Ubuntu Italic', 'Ubuntu Bold' of 'Ubuntu Bold Italic'.

Alle browsers: de webfonts worden niet mooi weergegeven

De fonts die door de maker van het systeem worden geleverd, zijn zo gemaakt dat ze er op dat systeem in de regel prachtig uitzien. Dat is voor webfonts lang niet altijd het geval voor alle systemen en voor alle browsers. Bovendien kan het ook nog 'ns sterk afhangen van de instellingen op 'n bepaalde computer, of van 'n bepaalde browser.

In iets oudere Windows-systemen is ClearType vaak nodig om andere fonts dan de systeemfonts goed weer te geven. Maar ClearType moet vaak eerst nog worden gedownload. En de gemiddelde gebruiker denkt bij ClearType vermoedelijk eerder aan 'n klierig type, dan aan 'n manier om fonts beter weer te geven.

Safari op Windows 7. Links de weergave voor 'n tft-scherm, rechts de standaardweergave.

Hierboven staat twee keer dezelfde sterk vergrote letter. Beide screenshots zijn gemaakt in Safari op Windows 7 op dezelfde machine. Het is de 'B' uit het kopje 'Ubuntu'. Het enige dat is veranderd, is een instelling in Safari zelf. Rechts staat de standaardinstelling, zoals die na installeren op Windows is. Links is de instelling aangepast aan het gebruikte soort beeldscherm.

Je zou het misschien niet zeggen, omdat het maar om kleine verschillen lijkt te gaan, maar de linkerletter is bij 'n gangbare lettergrootte echt 'n heel stuk beter dan de letter rechts. Die paar extra pixel links zorgen ervoor dat de linkerletter voor het oog mooie ronde vormen heeft, terwijl de rechterletter blokkerig is. Het is allemaal gewoon nep en suggestie, maar vertel dat maar 'ns aan je oog. (En leg daarna maar 'ns aan je omgeving uit dat je gezellig met je oog hebt gekeuveld.)

Op dit soort instellingen heb je natuurlijk geen enkele invloed. Daarom is uitgebreid testen van de gebruikte webfonts echt heel erg belangrijk. Je bedoeling is, naar ik aanneem, dat de pagina er extra mooi uit gaat zien, en niet extra blokkerig.

Alle browsers: je ziet geen webfont, maar gewone standaardfonts

Als het webfont om een of andere reden niet werkt, tonen alle browsers de tekst in 'n font dat wel beschikbaar is.

Het niet gebruiken van het webfont kan 'n heel scala aan oorzaken hebben, soms afhankelijk van de gebruikte browser. 'n Aantal mogelijke oorzaken staan hieronder.

Soms worden webfonts geblokkeerd door de beveiligingsinstellingen van een browser. Webfonts kunnen ook worden gebruikt om malware te verspreiden. De extensie NoScript bijvoorbeeld blokkeert om die reden in Firefox standaard webfonts. Deze extensie ken ik toevallig, maar er zijn ongetwijfeld nog meer van dit soort extensies, instellingen, enz.

Als het in één specifieke browser niet werkt, ligt bij zoiets mogelijk de oorzaak.

Als het alleen in Firefox en Internet Explorer 9 niet werkt, komt dat mogelijk doordat de fonts in een ander domein staan dan de site zelf. Vanwege veiligheidsredenen blokkeren Internet Explorer 9 en Firefox standaard webfonts uit een ander domein, dan waar je site staat. Waarschijnlijk gaan in de toekomst andere browsers dit ook doen. Het domein waar de fonts staan, moet expliciet toestemming geven om de fonts te gebruiken.

Als je fonts op een domein staan, waar Apache als server wordt gebruikt, kun je de blokkade mogelijk opheffen door iets op te nemen in het .htaccess-bestand. Niet elke hoster staat dit toe, maar als je de mogelijkheid hebt, moet je het volgende in de .htaccess zetten:

	<FilesMatch "\.(ttf|eot|woff|svg)$">
	    <IfModule mod_headers.c>
		Header set Access-Control-Allow-Origin
		    "https://www.css-voorbeelden.nl"
	    </IfModule>
	</FilesMatch>

Waar www.css-voorbeelden.nl staat, vul je je eigen domeinnaam in.

Er is een kans dat deze manier om webfonts vanuit een ander domein toe te staan, in de toekomst gaat veranderen. In de specificatie wordt hier expliciet voor gewaarschuwd.

(Dit is trouwens ook de manier, waarop webfonts services werken: toestemming geven aan de sites die gebruik mogen maken van hun fonts. Of, in het geval van gratis fonts zoals bij Google, gewoon "*" gebruiken in plaats van een domeinnaam, zodat iedereen wordt toegelaten.)

Alle browsers: cursief, vet, en dergelijke zien er in elke browser anders uit.

Als je één font gebruikt voor normale letters én cursief én vet, zoals in het voorbeeld bij Jinky is gedaan, maakt de browser er zelf cursief en dergelijke van. Het resultaat daarvan is afhankelijk van het besturingssysteem en de gebruikte browser en kan enorm verschillen. Het resultaat heeft in ieder geval één gemeenschappelijke factor: het is in de regel niet om aan te zien.

Een font dat geen speciaal ontworpen cursieve, vette, enz. variant heeft, zou ook niet zo weergegeven moeten worden. In het voorbeeld wordt bij Jinky als afschrikwekkend voorbeeld toch vet en cursief weergegeven, terwijl daar geen speciale fonts voor aanwezig zijn. De browser probeert er het beste van te maken:

Dezelfde machine met Windows 7. Links Google Chrome, rechts Safari.

Laat ik het zo zeggen: 'het beste' zoals hierboven weergegeven geeft stof voor levendige discussies op de lange winteravonden over de definitie van de inhoud van het begrip 'het beste'.

Hier ziet Google Chrome er beter uit, maar voor hetzelfde geld was het omgekeerd geweest. Maar echt mooi ziet het er in geen van tweeën uit. En ik kan alvast verklappen dat dit voor álle browsers geldt.

Een goede leesbaarheid is ook bepaald niet gegarandeerd, als de browser zelf aan het ontwerpen slaat. Bij cursief doet de browser in feite niet meer dan de normale letters enigszins kantelen. Bij de Toren van Pisa trekt dat veel bezoekers, maar of dat ook zo is, als je op deze manier je site wilt verfraaien...

(Overigens zegt het ontbreken van een cursieve variant bij Jinky niets over de kwaliteit van dit font. De maker heeft het alleen niet bedoeld om te gebruiken voor cursieve tekst en dergelijke.)

Een browser is gewoon geen typograaf. Het ontwerpen van een goed font is een vak.

Op de afbeelding staan helemaal links twee letters in de in het voorbeeld gebruikte gewone Ubuntu Mono. Gelijk daarnaast staan dezelfde twee letters cursief. Dat wil zeggen: de browser heeft de normale letters zelf cursief weergegeven. In het midden staan de twee letters in Ubuntu Mono cursief, zoals de typograaf het heeft ontworpen: een totaal andere cursieve letter dan wat de browser ervan bakt. Hier is echt duidelijk te zien dat de browser de letters alleen maar een soort schop geeft, terwijl echte cursieve tekens speciaal ontworpen worden.

De vier letters rechts zijn de normale Jinky en de 'cursieve' Jinky. Althans: wat de browser voor cursief houdt, want er bestaat geen cursieve Jinky. Ook hier is weer goed te zien dat de browser niets anders doet dan de normale letters schuin neerzetten, alsof ze dronken tegen een lantaarnpaal hangen.

Met aparte fonts voor cursief, vet, enz., wordt het dus wel veel mooier en de weergave in verschillende browsers en op verschillende systemen is altijd (vrijwel) hetzelfde, maar de laadtijd neemt ook sterk toe. Iets om goed over na te denken voor je webfonts gaat gebruiken, zeker bij een site voor mobiele apparaten.

Alle browsers: de tekst flikkert voordat het webfont wordt weergegeven

Als het webfont om een of andere reden niet werkt, tonen alle browsers de tekst in een wel beschikbaar font. Omdat het webfont geladen moet worden, voordat het beschikbaar is, zit er een (korte) tijd tussen het laden van de pagina met html - en de daarin staande tekst - en het webfont. Die (korte) tijd wordt door verschillende browsers op verschillende manieren overbrugd. Omdat dat in de browser zit ingebakken, heb je daar verder geen invloed op. Mogelijk wordt het flikkeren hierdoor veroorzaakt.

Op het moment van schrijven handelen de verschillende browsers dit als volgt af:

Firefox versie 3.5 en eerder, Opera en Internet Explorer 9 tonen de tekst eerst in een lokaal aanwezig font, dat wordt vervangen door het webfont. Dit verklaart mogelijk het flikkeren: je ziet de tekst heel kort in een lokaal font, waarna de tekst gelijk vervangen wordt door het webfont.

Firefox versie 4 en later: het webfont wordt gelijk weergegeven. Pas na drie seconden wordt een ander font gebruikt. Bij een trage verbinding kan het dus maximaal drie seconden duren, voor de tekst zichtbaar wordt.

Google Chrome en Safari: het webfont wordt gelijk weergegeven. Pas na één seconde wordt een ander font gebruikt. Bij een trage verbinding kan het dus maximaal één seconde duren, voor de tekst zichtbaar wordt.

Google heeft een JavaScript om onder andere te zorgen dat alle browsers zich hetzelfde gedragen tijdens het downloaden van de fonts. Ik neem aan dat Google dat niet alleen uit naastenliefde doet, maar ook om gegevens over bezoek aan de site te verkrijgen. Mocht je dit hulpmiddel van Google willen gebruiken, zoek dan naar WebFont Loader.

Volgens 24ways.org/2010/using-the-webfont-loader-to-make-browsers-behave-the-same zou je dit script ook lokaal moeten kunnen installeren, maar dat heb ik verder niet uitgeprobeerd.

Alle browsers: je ziet wel een webfont, maar geen cursief of vet

Als je maar één font gebruikt en dat door de browser cursief of vet laat weergeven met behulp van font-weight: bold; of font-style: italic; moet je in de @font-face-regel font-style: normal; font-weight: normal; toevoegen. Zoals in dit voorbeeld bij de regel voor Jinky is gedaan.

Als je dat niet doet, gaan Safari en Google Chrome ervan uit dat het normale font ook gebruikt moet worden voor cursief en vet. Voeg je die twee eigenschappen wel toe in de @font-face-regel, dan kun je op de normale manier font-weight en font-style gebruiken.

(Dat het dan waarschijnlijk niet mooi wordt, omdat de ontwerper van het font nooit heeft bedoeld dat de browser het zo gruwelijk zou mishandelen, is een andere zaak. Het met een botte kwast overkalken van een font is iets heel anders dan een vet font, net zoals het in een dronken bui omver kegelen van letters iets heel anders is dan een cursief font.)

Alle browsers: je ziet wel een webfont, maar vet is te vet en cursief is te cursief

Als je verschillende fonts gebruikt voor gewoon, cursief, enz., moet je bij elk font opgeven waarvoor het wordt gebruikt. Hoe dit moet staat bij font-weight: normal; font-style: normal;. Daar staat ook een voorbeeld van wat hier wordt bedoeld.

Wijzigingen

Alleen grotere wijzigingen worden hier vermeld, geen dingen als een link die is geüpdatet.

23 oktober 2011:

Nieuw opgenomen.

7 augustus 2012:

• Hele hoofdstukje Getest in vervangen. Daarin stond abusievelijk dat ook was getest in Internet Explorer 6, terwijl dit al niet meer gebeurde. Dit is ook gelijk gecorrigeerd.
• Bovenin de code <meta name="viewport" content="width=device-width, initial-scale=1"> toegevoegd. De reden daarvoor staat bij <meta name="viewport".... Omdat de pagina in feite al geschikt was voor mobiel, is er in de code verder niets veranderd.
• Bij <style> en links naar stylesheet type="text/css" weggehaald, omdat dit bij html5 standaard al zo is.
• Bij Bekende problemen info over Opera Mini en Android browser toegevoegd.
• font-stretch wordt inmiddels ook door Firefox ondersteund.

15 september 2013:

Koe van een fout bij omschrijving unicode-range gecorrigeerd.