Alle CSS centrerings eksempler kan ses i aktion her

Horisontal centrering af tekst og billeder

Simpel text-align centrering:

<img src="image.jpg" alt="alternative text" />
<p>Centered text</p>

img, p { text-align:center; }

[ Se eksempel ]

Vertikal centrering af tekst og billeder

I de "gode" gamle tabel dage var det ingen problemer at centrere vertikalt. Men efter tabel-fri-design så dagens lys blev det til en større udfordring og nærmest umuligt for mit vedkommende. I dag er det heldigvis blevet "nemt" igen, der er selvfølgelig de normale Internet Explorer, IE, problemer! Tricket er, at få et element til at opføre sig som et tabel element, hvilket gøres vha. display attributten (display: table; og display:table-cell;). IE 6 og 7 understøtter desværre ikke table værdien, hvorfor en omvej må tages

 <ul>
    <li>
       <a href="#">
          <span>Vertical<br />centered<br />text</span>
          <!--[if lte ie 7]><b></b><![endif]-->
       </a>
    </li>
    <li>
       <a href="#">
          <span>Line one<br />Line two<br />Line three</span>
          <!--[if lte ie 7]><b></b><![endif]-->
       </a>
    </li>
    <li>
       <a href="#">
          <span>Only two<br />lines here</span>
          <!--[if lte ie 7]><b></b><![endif]-->
       </a>
    </li>
 </ul>

 ul { margin:0 auto; width:400px; }
 li { float:left; }
 a { display: table; height: 100px; }
 span { display: table-cell; vertical-align: middle; }

 IE 6 + 7 Styling:
 span { display: inline-block; }
 b { display: inline-block; height: 100%; vertical-align: middle; }

[ Se eksempel ]

Horisontal centrering af block elementer med fast bredde

Horisontal centrering med en fast bredde kan løses på mange måder, men den nemmeste og mest rene er immervæk "margin: 0 auto" tricket!

<ul>
   <li><a href="#">Item 1</a></li>
   <li><a href="#">Item 2</a></li>
   <li><a href="#">Item 3</a></li>
</ul>

ul { margin:0 auto; width:400px; }
li { float:left; width:33,3%;}

[ Se eksempel ]

Horisontal centrering af block elementer med dynamisk bredde

Horisontal centrering af menuer med dynamisk bredde har givet mig mange kvæler, hvorfor javascript har været min ven. Dette er dog ikke nødvendigt mere, hvorfor en pænere og mere ren løsning med CSS kan bruges

<ul>
   <li><a href="#">First item</a></li>
   <li><a href="#">Item in the middle</a></li>
   <li><a href="#">Last item, no more items</a></li>
</ul>

ul, li { float:left; position:relative; }
ul { left:50%; }
li { right:50%; }

[ Se eksempel ]

Vertikal og horisontal centrering af baggrundsbilleder

En meget effektiv men også overset måde at centrere på er vha background-position. Du undrer dig sikkert over, at jeg skriver overset, men det er min erfaring, at udviklere som kun kender løst til CSS ikke kender attributten!

<div class="bg"></div>

.bg { background: url('image.jpg') center center no-repeat; }

[ Se eksempel ]

Se alle kodeeksempler med vertikal og horisontal centrering her

Min påstand er, at alle udviklere på et tidspunkt kommer til at støde på front-end arbejde herunder CSS og markup. Mange af de tungere drenge bryder sig ofte ikke om det, hvilket til tider resulterer i spaghetti kode! Om det er manglende interesse/viden eller bare arrogance, skal jeg ikke kunne sige. Ved at følge nogle simple principper kan det hele blive lidt sjovere og nemmere for alle parter, for de tunge drenge, for dem som er begejstret for det og sidst men ikke mindst for dem som skal vedligeholde det efterfølgende.

1. Markup før CSS

Lav altid dit markup før du begynder at style. Sørg for at den så vidt muligt er valid, og at den er semantisk opbygget. En god tommelfingerregel er, at ens markup skal give mening uden CSS.

2. Lav valid kode

Ligesom med dit markup skal dit CSS være valid. Hvis du er i tvivl, kan du validere dine stylesheets via W3's CSS validator. Mange undervurderer vigtigheden af valid kode, så længe det bare virker. Men ved ikke at have valid kode, kan man ikke være sikker på, at ens kode vil virke i fremtiden. Ved at følge en vis standard undgår vi kaos og monopolisme.

3. Normalisering

Normaliser altid dit stylesheet inden du går i gang. Forskellige browsere har forskellige default værdier for de forskellige elementer, hvorfor det til tider kan være umuligt at lave en side, der opfører sig ens cross-browser uden brug af reset. Hvor meget eller hvor lidt der skal resettes er en temperamentssag. Herunder er listet nogle eksempler:

1. CSS Reset Reloaded by Eric Meyer
2. Yahoo! UI Library: Reset CSS
3. CSS Global Styles Reset by Kyle Neath

Være opmærksom på at det korte og brugte reset: * { margin: 0; padding: 0; } er et misforstået reset. Det er "tungere" at renderer (især med store websider), da det definerer regler for hvert enkelt element i ens dokument og nulstiller alt, hvorfor det ikke er anbefalingsværdigt.

4. Navngivning

Navngivningen er vigtig og desværre også utrolig undervurderet. Uanset hvad du vælger så vær konsekvent. Hold dig evt. til engelsk, brug camelCaseMedLilleBegyndelsebogstav eller adskil ord med bindestreg (-)  og giv som udgangspunkt strukturelle navne frem for præsentationsmæssige.
Et strukturelt navn beskriver, hvad det er for et element, du vil henvise til frem for et præsentationsmæssigt navn, som beskriver, hvor elementet befinder sig på siden, eller hvordan det ser ud.

Præsentationsmæssige navne:

topNav, leftTopLogo, leftContent, redBoldLink

Strukturelle navne:

primaryNav, branding, mainContent, externalLink

De præsentationsmæssige navne låser elementet fast, hvorfor de skal undgås. Hvad nu hvis din top menu (#topNav) pludselig skal ligge til venstre for dit indhold? Der findes dog som altid undtagelser, hvor de præsentationsmæssige navne giver mening, som næste punkt vil illustrere.

5. Lav genanvendelig kode

Du er sikkert stødt på ordet "object-oriented CSS" også kaldet OOCSS?! Hvis ikke gør du det nu. Selve navnet, OOCSS, er en smule misvisende og forvirrede mig, da jeg første gang stødte på det. OOCSS er ikke, hvad man traditionelt vil betegne som objekt-orienteret programmering, OOP, men i stedet benytter man nogle af OOPs principper såsom polymorfi, abstraktion, arv mm.
Ideen bag OOCSS er at lave mindre og mere genanvendeligt CSS vha klasser. For en dybere redegørelse henvises til "opfinderens" hjemmeside, Nicole Sullivan.

Hvordan opnår man så genanvendeligt CSS? Først et eksempel på, hvordan man ikke skal gøre:

CSS:
#element1 a.btn {background-color:#000;color:#fff;}
#element2 a.btn2 {background-color:#000;color:#fff;}
#element1 a.btnWithBorder {background-color: #000;border:1px solid #ccc;color:#fff;}
Markup:
<div id="element1">
   <a href="#" class="btn">Knap 1</a>
   <a href="#" class="btnWithBorder">Knap 1 med border</a>
</div>
<div id="element2">
   <a href="#" class="btn2">Knap 2</a>
</div>

Her indkapsler og fastlåser du din knap til et anchor tag samt id element og opnår derved redundans CSS samt kode, der ikke kan genbruges! Fjern afhængighederne og du har genanvendelig kode:

CSS:
.btn {background-color:#000;color:#fff;}
.border {border:1px solid #ccc;}
Markup:
<div id="element1">
   <a href="#" class="btn">Knap 1</a>
   <a href="#" class="btn border">Knap 1 med border</a>
</div>
<div id="element2">
   <a href="#" class="btn">Knap 2</a>
</div>

Nu kan dine klasser bruges på alle typer af objekter og ikke kun anchor tagget:

<button type="button" class="btn">Knap</button>
<div class="btn">Knap</div>

6. CSS struktur

CSS strukturen bliver ofte glemt eller nedprioriteret, hvilket er ærgerligt, da den kan spare dig og andre for en masse spildtid! Et godt råd er, at man i sit team/udviklingsmiljø aftaler nogle strukturelle regler, så man nemt kan arbejde på tværs af hinandens projekter.  Eksempler på strukturelle regler kunne være:

• Stylesheets inddeles i afsnit, fx via sektioner eller selectors.
• En regels egenskaber opstilles i alfabetisk rækkefølge for at få et hurtigere overblik (#element { float: left; height: 250px; width: 250px; }).
• Man har et element pr linje kontra en egenskab pr linje i sit stylesheet.
• Hierarkisk inddeling.
• etc.

Hvis det skal have nogen effekt, er det vigtigt, at man er konsekvent. Man laver en ens struktur for at gøre udviklingen nemmere her og nu samt i fremtiden. Når man skal have sit projekt live bliver strukturen ligegyldig, hvorfor man altid skal minify sine stylesheets for at spare kb.

7. Stylesheets

Stylesheets skal altid være placeret i toppen fordi:

1. W3 dikterer, at stylesheets skal være i toppen (head), medmindre det er inline-styling.
2. Ved at placere stylesheets i toppen opnår man, at ens side loader progressivt, hvilket er vigtigt, hvis din side har meget indhold, eller brugeren sidder bag en langsom forbindelse. Siden viser indholdet så snart, det er klart, og brugeren har en indikation af, at siden er ved at loade. Denne indikation er meget vigtig for brugervenligheden. Hvis man derimod indsatte stylesheets nær bunden, ville man i mange browsere (eksempelvis Internet Explorer) miste den progressiv hentning og stå tilbage med en hvid blank side, da browsere blokerer renderingen for at forhindre at skulle gentegne elementer, der måtte ændre sig.

Der findes mange meninger omkring, hvordan du opnår den bedste performance samt struktur mht stylesheet inddelingen. Jeg er dog ikke stødt på en løsning, der kan bruges bestandigt og som hos så meget andet, mener jeg, at det skal vurderes fra projekt til projekt. Oftest ender jeg med et setup, hvor jeg samler mit reset jf. punkt 3, klasse objekter jf. punkt 5 og fællesregler (element styling, h1, h2 etc) i et stylesheet og, hvis nødvendigt, et side-specifikt stylesheet (internt eller eksternt), hvor regler der kun gælder for den aktuelle side er.

8. Brug shortcase

Brug shortcase, da det formindsker din kode og giver et bedre overblik. Et eksempel illustrer pointen:

#element { margin-top: 15px; margin-right: 10px; margin-bottom: 15px; margin-left: 10px; }

bliver til

#element { margin: 15px 10px; }

Du kan også bruge shortcase hos følgende egenskaber; background, border, font, list, margin, outline og padding. Dustin Diaz har skrevet en fremragende guide til emnet.

9. Spring mellemledet over

Som i den virkelige verden er det oftest billigst for forbrugeren, at mellemledet bliver fjernet, og det er det også hos CSS. Mellemledet er ofte ubrugeligt og fylder kun ekstra i dit stylesheet, hvorfor det skal fjernes. Der findes dog situationer, hvor du kan blive tvungen til at inkludere det men som udgangspunkt; fjern det:

#element ul li a span.class

bliver til

.class eller #element .class hvis man har behov for indkapsling

10. Undgå hacks

Hold dig fra at bruge hacks! Hvad enten det er * hack, _ hack eller lignende. Brug i stedet Conditional Comments til fx at indsætte et Internet Explorer 6 specifikt stylesheet.

<!--[if IE 6]>
<link type="text/css" href="ie6styling.css" rel="stylesheet">
<![endif]-->

Eller til at sætte en klasse på html tagget for derved at kunne style specifikt til en ønsket version af IE.

<!--[if lt IE 7 ]> <html lang="en" class="no-js ie6"><![endif]-->
<!--[if IE 7 ]> <html lang="en" class="no-js ie7"><![endif]-->
<!--[if IE 8 ]> <html lang="en" class="no-js ie8"><![endif]-->
<!--[if IE 9 ]> <html lang="en" class="no-js ie9"><![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html lang="en" class="no-js"> <!--<![endif]-->

11. Adskillelse

Markup og CSS er som Batman og Robin. De er fantastiske sammen, dog kan Batman fint klare sig alene, hvorimod Robin er ubrugelig uden Batman.
Man må aldrig begynde at sammensmelte markup og CSS og lave noget så uhyggeligt som inline styling. For at sikre fleksibilitet og overblik er det vigtigt at alt styling adskilles fra markup og kun lever i et stylesheet. Nu siger du sikkert, at der findes situationer, hvor inline-styling er eneste løsning, og ja det gør der, men brug det kun som sidste udvej, og ikke fordi du er doven.

12. Divitus, classitis og idikus

Undgå at få divitus, classitis eller idikus. Generelt for alle 3 sygdomme er, at man overforbruger. Man kan sammenligne det med et sønderjysk kaffebord, hvor der minimum er 14 forskellige kager, 7 bløde og 7 hårde, hvilket er helt unødvendigt. Derimod ville 1-2 kager fra hver kategori have været rigeligt.
Divitus er når man bruger for mange div'er. Mange nybegynder har en tendens til at smide en div rundt om alt:

<div id="mainHeader"><h1>Min overskift</h1></div>

Div'en er ikke nødvendig, og man kan i stedet skrive

<h1>Min overskrift</h1>

og så style på h1 i stedet for #mainHeader. Dog må man ikke være bange for at bruge div'er!  Jeg kan godt lide html5 tankegangen, som giver bedre overblik og en pænere struktur, hvorfor jeg til tider indkapsler hovedområder i en div med et sigende id!

Classitis og idikus minder meget om divitus:

<ul id="unsortedList">
  <li class="listItem firstItem">Item 1</li>
  <li class="listItem">Item 2</li>
  <li class="listItem">Item 3</li>
</ul>

Det er ikke nødvendigt at overklistre alle selectors med klasser og id'er:

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

Brug i stedet de elementer der allerede er til rådighed (ul, li) og, hvis IE6 også er død for dig, de smarte og hjælpefulde CSS selectors!

li:first-child   = Første li element.
ul > li          = Alle ul'ers børn der er li.
li + li          = Alle li'er der har samme forældre,
                   og hvor der kommer en li lige efter en li.

13. Vær god til matematik

Undersøgelser har vist, at personer med gode matematiske færdigheder har nemmere ved at programmere, hvilket også gavner, når man skal forstå, hvilken regel der er præcedens ved kollision. Fx kan et element have 2 regler der modsiger hinanden:

HTML:
<h1 class="h1">Header</h1>

CSS:
.h1{color:white;}
h1{color:black;}

Mange vil måske tro, at sidste regel altid er vigtigst, og at header teksten derfor vil være sort! Men hos CSS er der andre faktorer, der spiller ind. Først vægtes måden din styling bliver indlæst på:

1. prioritet: Inline styling
2. prioritet: Internt stylesheet
3. prioritet: Eksternt stylesheet
(4. prioritet: Browser default)

Dernæst vægtes attributterne:

li             {...}  /* a=0 b=0 c=1 -> specificity =   1 */
ul li          {...}  /* a=0 b=0 c=2 -> specificity =   2 */
ul ol li       {...}  /* a=0 b=0 c=3 -> specificity =   3 */
li.class       {...}  /* a=0 b=1 c=1 -> specificity =  11 */
ul ol li.class {...}  /* a=0 b=1 c=3 -> specificity =  13 */
#element       {...}  /* a=1 b=0 c=0 -> specificity = 100 */

hvor a repræsentere antal #id attributter, b antal klasse attributter og c antal tag elementer.  Jo højere tallet er, jo højere vægtning. I fornævnte eksempel vil header teksten være hvid, da klassen (.h1) vægtes med 10 point og tagget (h1) med 1 point.

14. Vær progressiv

I stedet for at udvikle til laveste fællesnævner, bør man være progressiv og anvende den nye teknologi, browsere løbende får, så længe siden stadig fungerer funktionelt hos laveste fællesnævner. Fx understøtter firefox bl.a. drag and drop af filer, hvor en bruger, der skal uploade en fil, kan dragge og droppe filen direkte ind i browseren og derved spare adskillige kliks. IE understøtter i skrivende stund ikke denne feature, hvorfor det selvfølgelig stadig skal være muligt at uploade en fil på den gammeldags måde. Her får brugeren med den bedre browsere bare en bedre oplevelse.

Et andet eksempel kunne være, hvor du har et element, der skal have runde hjørner og en gradient baggrund. I stedet for at skulle være afhængig af et stykke grafik eller flere, kan du lave runde hjørner samt gradient med CSS. Dette understøttes dog ikke i alle browser, nærmere bestemt IE, så når man udvikler efter laveste fællesnævner, bliver man nødt til at løse det med grafik, som gør siden tungere. Men nu er vi jo progressive, og derfor vælger vi den lettere og elegante CSS løsning, og lader brugerne af IE se et firkantet element med fast baggrund, og alle andre et lækkert rundt element med gradient. Siden kan stadig bruges af IE brugere, og IE brugerne ser stadig samme indhold, som andre brugere. Dog kan designere være tunge at danse med, og ofte kan det ende i et kompromis, hvor man bruger CSS3 de steder, der understøtter det og ellers grafik (IE).

15. Kend dine elementer

Som med alle programmeringssprog er det en god ide at kende til basis funktionaliteterne. Nogle gange er området dog så stort, at en del erfaring er påkrævet. CSS har derimod et overkommeligt antal basis elementer, der derfor gør det hurtigere og nemmere at få et overblik og derved at kunne vælge de rigtige elementer i den rigtige situation. Lær elementerne at kende før du går i gang, float vs. position, display vs. visibility, tabel vs. div etc.

16. Centrer med margin

Centrer med margin: 0 auto; i stedet for fx at fastkode en fast padding i venstre side. For at centrer med margin skal du definere en bredde:

#element { margin: 0 auto; width: 800px; }

17. Vær doven

Sidste punkt som i øvrigt gælder programmering generelt er, at man skal være doven. Der findes et utal af udviklere, som allerede har haft de problemstillinger, som du støder på, hvorfor det vil være fjollet ikke at benytte sig af deres viden og erfaringer. Genbrug dine og andres komponenter og brug de erfaringer, der allerede er tilgængelige. I CSS støder man på mange lignende problemstillinger, hvorfor man nemt kan ende som Sisyfos!

SLUT

Det var mit bud på, hvordan man ved hjælp af nogle simple principper, opnår bedre og mere overskueligt CSS og markup. Vigtigst af alt er, at man er konsekvent hele vejen igennem og tro mod kode standarderne. Sammen kan vi gøre verden til et bedre sted!

P.S. Har jeg glemt noget, eller er du bare dybt enig/uenig så smid gerne en kommentar.

OPDATERET: Efter at Internet Explorer 9 har set dagens lys, er man tvungen til en syntaks ændring, hvis man vil have en bulletproof @font-face syntaks! Se mere under afsnittet "Hvordan bruger man font-face?".

Hvorfor bruge font-face?

I dag er vi sørgeligt nok stadig begrænset af få standard fonte, der er websikre. Man kan dog altid bruge ikke-websikre fonte og håbe på, at ens brugere har den valgte font på sin computer. Dette er selvfølgeligt meget usikkert, og man risikerer at ødelægge sit design samt struktur, hvorfor man i stedet embetter sine specielle fonte i form af grafik. Men takket være font-face er den tid nu ovre.

Ulemper ved grafik embetting:

• Ekstra arbejde - Hver gang du vil bruge din font, skal du lave det som grafik. En lille rettelse betyder, at designeren skal åbne sit billedbehandling program, lave rettelsen, gemme filen i det ønskede billedformat og uploade billedet.
• Tungere sider - I stedet for ren tekst har du grafik, som fylder mere og koster HTTP-requests. Stor skift størrelse = stor grafik.
• Manglende indeksering - Web crawlers kan ikke indeksere tekst i grafik. Dog kan (læs skal) man give sine billeder alt beskrivelser, hvilke bliver indekseret.

Ulemper ved font-face:

• Manglende standard - I skrivende stund findes der desværre ikke et font format, der understøttes af de meste brugte browsere, hvorfor det kræver, at man som minimum har fonten i formatet .eot, .ttf og .svg. Som det kan ses af nedenstående tabel tyder det dog på, at WOFF bliver fremtidens standard webfont format!

Font-face browser support

Hvordan bruger man font-face?

En mere dybdegående forklaring på font-face syntaks kan læses på Paul Irish blog indlæg; Bulletproof @font-face syntax. Nedenstående eksempel er mit forslående minimum setup for at understøtte alle overstående browsere samt iphone/ipad. Url'en til svg fonten har et id (#id) , som skal stemme overens med id'et i svg filen.

@font-face {
   font-family: 'Font Navn';
   src: url('font.eot');
   src: local('☺'),
      url('font.ttf') format('truetype'),
      url('font.svg#id') format('svg');
   font-weight: normal;
   font-style: normal;
}

Ny bulletproof syntaks efter at IE9 er udkommet:

@font-face {
   font-family: 'font Navn';
   src: url('font.eot'); /* IE9 Compat Modes */
   src: url('font.eot?#iefix') format('eot'), /* IE6-IE8 */
     url('font.woff') format('woff'), /* Modern Browsers */
     url('font.ttf')  format('truetype'), /* Safari, Android, iOS */
     url('font.svg#id') format('svg'); /* Legacy iOS */
}

Fonten kan nu bruges som enhver anden standard font:

h1 { font: 100% 'Font Navn', Arial, sans-serif; }

De forskellige font formater kan genereres med font squirrel's font generator. Husk at sikre at du har tilladelse til at bruge fonten som @font-face.

Undgå "blink" effekten!

Først lidt baggrundsviden. IE downloader .eot filen så snart den støder på @font-face erklæringen, hvorimod Gecko, Webkit og Opera alle venter indtil de støder på markup, der har en CSS regel, hvori den specielle font indgår. Webkit har en feature/bug, der gør, at fonten først bliver vist, når den er indlæst, hvor Gecko og Opera viser en standard font imens, og så genrender når fonten er hentet.
Problemet med Webkit er, at hvis en bruger sidder bag en langsom forbindelse, vil brugeren ikke se teksten før den har hentet font filen, hvorfor brugeren kan se en (delvis) blank side i op til flere minutter afhængig af forbindelsen.
Problemet i Gecko og Opera er, at brugeren vil kunne se genrederingen (blinket), og at designet muligvis vil brække indtil fonten er hentet. Nedenstående billede illustrerer blinket og er et simplificeret eksempel på, at strukturen også kan ændre sig.

Font-face "blink" eksempel

For at opnå Webkit featuren i Gecko og Opera findes der et javascript bibliotek, WebFont Loader, der vha klasser på html tagget fortæller når fonten er hentet, hvorfor du selv kan gemme teksten via CSS indtil fonten er hentet, og dermed undgå blinket:

<script src="http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js"></script>
<script type="text/javascript">
   WebFont.load({
      custom: {
         families: ['Font Navn'],
         urls : ['http://dinbror.dk/font-face-stylesheet.css']
      }
   });
</script>

CSS:

.wf-loading h1 {
   visibility:hidden;
}
.wf-active h1, .wf-inactive h1 {
   visibility: visible;
   font-family: 'Font Navn', Arial, sans-serif;
}

Ulempen er ligesom hos Webkit, at teksten ikke kan ses imens fonten hentes, og at man nu også skal hente og være afhængig af et javascript bibliotek. Dog kan man i stedet for at gemme teksten helt tilpasse den, så den i stedet passer størrelsesmæssigt med font-face fonten. Et lille tip er, at man ikke gemmer teksten i IE, da det ikke er nødvendigt (IE downloader .eot filen så snart den støder på @font-face erklæringen), og da IE ikke er kendt for sin hurtige rendering af javascript.

En anden og mindre ressourcekrævende løsning, hvor man dog kun minimere blinket, og som pt kun er understøttet i Gecko, er CSS attributten font-size-adjust. Den giver dig mulighed for at normalisere x-højden på tværs af en font, hvorfor forskellen reduceres og designet holdes konstant!

Hjælp, font-face virker ikke i Firefox!?

Selvom font-face er understøttet i Firefox, kan Firefox godt drille. Firefox tillader ikke cross-domain fonte som standard, hvilket betyder, at fonten skal ligge på samme domæne, endda samme sub-domæne medmindre man kan tilføje en “Access-Control-Allow-Origin” header til fonten. Dette er ikke altid en mulighed, men fortvivl ikke. Der findes selvfølgelig også en løsning på det. Det er måske ikke den pæneste løsning og heller ikke helt uden bivirkninger.  Løsningen er at embette fonten i sit stylesheet som Base64. Hvis du bruger font squirrel's font generator kan du vælge "Expert", og herefter sætte flueben i Base64 Encode under CSS options som nedenstående billede illustrerer.

Vælg Base64 Encode

Resultatet er, at ttf fonten nu i stedet bliver embettet i stylesheetet:

@font-face {
   font-family: 'Font Navn';
   src: url('font.eot');
   src: local('☺'),
      url("data:font/opentype;base64,[base64-encoded font her]");
      url('font.svg#id') format('svg');
   font-weight: normal;
   font-style: normal;
}

Bivirkningerne er, at stylesheetet bliver tungere, og at base64 encoding fylder mere selve ttf fonten.

Åhh nej @font-face virker ikke i IE9

Internet Explorer 9 kommer med mange gode opdateringer og standardiseringer, hvilket har medført ændringer i måden, hvad IE tillader. Det har bl.a. betydet, at IE9 som FF ikke tillader cross-domain font-linkning. Løsningen er som med FF, at tilføje en “Access-Control-Allow-Origin” header til fonten.

Problemer med WOFF
IE9 understøtter modsat sine forgængere .woff fonte. Hvis du benytter en IIS skal huske at tilføje .woff's MIME type til IIS'en for ikke at få en 404 not found:

<MimeType extention=".woff" type="application/x-font-woff" />

Hvis dette ikke er en mulighed, kan du også tvinge IE9 til at bruge .eot fonten i stedet ved at ændre formatet fra eot til embedded-opentype. IE9 supporterer formatet embedded-opentype modsat formatet eot, hvorfor fonten indlæses:

src: url('webfont.eot?#iefix') format('embedded-opentype')

EOT er som default kendt af IIS'en.

@font-face virker stadig ikke i IE9
Jeg er ikke selv stødt på problemet, men har læst at I nogle sjældne tilfælde vil @font-face fejle i IE pga. for mange karakter. Dette kan løses ved at tilføje et hash tegn efter spørgsmålstegnet:

src: url('font.eot?#iefix') format('eot')