De siste årene har mange aktører forsøkt å løse problemet med diverse hacks. Cufon, SIFR og script som lagrer tekst som bilder har gjort det mulig å bruke profilfonter istedet for systemfonter, men ingen standard har blitt satt og dessverre begrenser slike løsninger seg gjerne til bruk i titler.

Nå ser det imidlertid ut til å løsne. Nye standardiserte løsninger er på vei. Firefox har i sin siste versjon (Firefox 3.5) lagt inn en CSS regel som tillater å benytte fonter som ikke er installert på sluttbrukerens maskin. Med @font-face kan man lenke til fonter på samme måte som man kan med bilder! Både Opera og Safari støtter font.face, men dessverre ikke Internet Explorer og Googles nettleser, Chrome.

Et lite skår i gleden er at ikke bare den lykkelige designeren, men også kreti og pleti av sluttbrukere får tilgang på fontfilene når disse brukes på web. Dette er fontprodusentene fint lite interessert i. Noen som har forsøkt å løse dette er folkene bak Typekit. Typekit er en plattform som gir tilgang på både gratisfonter og kommersielle fonter samtidig som rettighetene ivaretas. Slik jeg har forstått det fungerer det i praksis slik at du logger deg inn, velger en font, ”styler” med en CSS-editor og genererer et javascript. Alt i et oversiktelig og enkelt brukergrensesnitt. Typekit er enda ikke lansert, men utvalgte brukere har fått teste en betaversjon.

W3C (World Wide Web Consortium), som godkjenner nye web standarder, vil kanskje gå god for et nytt forslag kalt .webfont. Dette formatet består av en komprimert fil hvor browseren, utifra meta-data, avgjør om fonten skal vises eller ikke. Microsoft har også foreslått sitt eget format EOT (Embedded OpenType) som standard, men med patentbeskyttet kode man må betale for. Ikke populært…

Det blir spennende å se hvilken retning webtypografien vil gå, både teknisk og kreativt. Kanskje sier vi farvel til Arial og Verdana, men må regne med å si hallo til Comic Sans? Grøss…

Skjermdump fra Typekit hentet fra Flickr

Takk til Kristoffer Dyrkorn for å ha sett igjennom teksten og kommet med fine innspill!

Dette innlegget er også postet på pixelpond.wordpress.com

<div id="content">
<div class="left column">
<h2>Velkommen til open.bekk.no</h2>
innhold</div>
<div class="right column">
    <a href="url">En link</a></div>
</div>

#content
  .left.column
    %h2 Velkommen til open.bekk.no
    %p innhold
  .right.column
    %a{:href => "url"} En link

Haml kommer med sin egen versjon av CSS, kalt Sass (Syntactically Awesome StyleSheets). Sass er en oversiktlig og god måte å skrive nøstede regler. I Sass kan man definere variabler, noe som gjør det enklere og raskere å endre verdier.

#header {
  background: #FFFFFF;
}
#header .error {
  color: #FF0000;
}
#header a {
  text-decoration: none
}
#header a:hover {
  text-decoration: underline
}

!error_color = #FF0000
 
#header
  :background #FFFFFF
 
  .error
    :color= !error_color
 
  a
    :text-decoration none
    :hover
      :text-decoration underline

Kombinasjonen Haml og Sass er utmerket for å lage raske prototyper. Selv om dette er laget for ruby, er det ikke noe i veien for å bruke det til ren html/css. Den største fordelen for rask prototyping er Sass. Det er mye raskere og mer oversiktlig å gjøre endringer i sass enn det er i css. Muligheten for variabler føles naturlig for en programmerer, og gjør også koden mer lesbar (!error_color sier leseren myer mer enn #FF0000).

Weblesere forstår ikke haml/sass. Du trenger derfor en server som kan oversette dette. En rask og enkel løsning er å bruke Serve. Serve fyrer opp en instans av Webrick fra katalogen du står i. Ønsker du muligheten til å bruke partials for å redusere duplisering i haml-filene, kan jeg anbefale å bruke Sinatra i stedet for Serve.

Så enkelt er det å komme i gang:

• ruby
• haml (“gem install haml” fra commandprompt)
• serve (“gem install serve” fra commandprompt)
• starte opp serve (“serve” fra commandprompt i ønsket katalog)