Ho già par­lato di come adat­tare una scala tipo­gra­fica usando le impo­sta­zioni di base di YUI¹.

Qualche tempo fa ho sco­perto que­sta pagina² di Iain Lamb³.

In que­sto caso, i valori otte­nuti per i titoli sono diversi, usando sem­pre la scala tra­di­zio­nale. Usando come valore base 13px otte­niamo⁴ 19,5px, 17,3px e 15,2px per h1, h2 e h3, rispet­ti­va­mente, invece di 24px, 21px e 18px.

La cosa curiosa è che pur dichia­rando appunto che viene usata la scala tipo­gra­fica tra­di­zio­nale i valori che ne risul­tano sono diversi. Bisognerebbe appro­fon­dire ma sul sito non c’è modo di farlo :-(

Mi è rica­pi­tato fra le mani que­sto arti­colo di Jason Santa Maria e volevo segna­larlo per­ché anche a distanza di qual­che tempo (è del 2008) rimane validissimo.

In poche parole

L’idea è molto sem­plice e con­si­ste nell’estrarre gli ele­menti di varia­bi­lità del nostro lay­out e asso­ciarvi delle classi nel foglio di stile. Così, ad esem­pio, le dimen­sioni che pos­siamo attri­buire a un’immagine diven­tano delle classi:

.one {width: 100px;}
.two {width: 210px;}

così come la loro posi­zione:

.left {float: left; margin-right: 20px;}
.right {float: right; margin-left: 20px;}

e così via.

A que­sto punto, sfrut­tando la pos­si­bi­lità di spe­ci­fi­care più classi per un dato ele­mento pos­siamo com­bi­nare quelle che ci servono.

Analogie

Questo approc­cio mi ricorda quello pre­sen­tato in Design Fast Websites; la com­po­si­zione delle classi sem­bra molto simile. A chi inte­ressa, l’autrice della pre­sen­ta­zione ha anche creato un fra­mework CSS basato sugli stessi prin­cipi, Object Oriented CSS, sca­ri­ca­bile da GitHub.

Altre appli­ca­zioni

Possiamo usare lo stesso sistema anche per le dimen­sioni delle font. Oltre a spe­ci­fi­care diret­ta­mente la dimen­sione del testo per un ele­mento, creiamo le classi cor­ri­spon­denti:

._24, h1 { font-size: 182%; }
._21, h2 { font-size: 161.6%; }
._18, h3 { font-size: 138.5%; }
._16, h4 { font-size: 123.1%; }

Nel mio post chi­lo­me­trico su @font-face ho accen­nato alla que­stione del font hin­ting e alle dif­fe­renze nel ren­de­ring delle font, in par­ti­co­lare, quello delle font OpenType CFF sotto Windows è net­ta­mente peg­giore di quelle TrueType ¹.

PostScript vs TrueType

Il motivo di que­sta dif­fe­renza è dovuto al fatto che il for­mato CFF ere­dita una serie di scelte fatte in pas­sato con il PostScript, in par­ti­co­lare la descri­zione dell’outline e, appunto, il modello di hinting.

Questi modelli, però, erano creati per le stam­panti a bassa riso­lu­zione e non per il moni­tor; vice­versa, il TrueType è stato pen­sato fin dall’inizio per il ren­de­ring a video.

Perché il CFF usa il modello del PostScript?

La scelta usata per il CFF è moti­vata dal fatto che il for­mato outline con le curve di Bézier cubi­che del PostScript è quello usato quasi tutti i pro­get­ti­sti di font e soprat­tutto il modello di hin­ting è molto più sem­plice e può essere in larga parte auto­ma­tiz­zato ².

In que­sto momento, quindi, la scelta del TrueType per @font-face sem­bra pra­ti­ca­mente obbli­gata, almeno fino al momento in cui il ren­de­ring tra­mite DirectWrite sarà suf­fi­cien­te­mente dif­fuso su Windows ³.

Introduzione

Una dei temi ricor­renti dell’anno appena tra­scorso nell’ambito dello svi­luppo web è stato sicu­ra­mente quello delle font. Ho pen­sato per­ciò di rac­co­gliere alcuni arti­coli com­parsi recen­te­mente per dare una pano­ra­mica della questione.

In par­ti­co­lare, vedremo in cosa con­si­ste a grandi linee l’uso di @font-face, i punti a cui fare atten­zione, le impli­ca­zioni posi­tive e nega­tive. Ho cer­cato di estrarre gli aspetti più pra­tici, riman­dando agli arti­coli ori­gi­nali (lin­kati nei titoli delle sezioni) per i det­ta­gli teo­rici e le moti­va­zioni che stanno die­tro le varie soluzioni.

Per gli impa­zienti, comun­que, ecco il rias­sunto. Anche se i passi in avanti sono stati signi­fi­ca­tivi, credo sia pru­dente limi­tare @font-face a titoli e cose del genere, con­ti­nuando ad usare le font clas­si­che per tutto il resto, magari rive­dendo con più atten­zione gli stack delle font dichia­rate nei fogli di stile.

How to use CSS @font-face #

Cominciamo con la domanda pra­tica: cosa biso­gna fare per usare @font-face? Questo:

@font-face {
  font-family: "Kimberley";
  src: url(http://www.princexml.com/fonts/larabie/ »
  kimberle.ttf) format("truetype");
}

In altre parole, dob­biamo defi­nire ori­gine e for­mato per la font Kymberley in modo da poterla poi usare nelle stesse moda­lità delle font già installate.

Fin qui la teo­ria, in pra­tica dob­biamo risol­vere la que­stione dei diversi for­mati delle font ¹. La cosa più veloce per risol­verle è gene­rare tutti quelli che ser­vono con Font Squirrel.

Una volta gene­rati i for­mati biso­gna irro­bu­stire la dichia­ra­zione che abbiamo visto prima per farla fun­zio­nare con i vari browser:

@font-face {
  font-family: "Your typeface";
  src: url("type/filename.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename.woff") format("woff"),
    url("type/filename.otf") format("opentype"),
    url("type/filename.svg#filename") format("svg");
  }

La com­bi­na­zione dei due src si prende cura di Explorer ²; i due local con­sen­tono al bro­w­ser di cer­care prima la font in locale, e sono due per­ché alcuni bro­w­ser usano il nome Postscript e altri il nome del file; il resto sono elen­cati i for­mati in ordine di desiderabilità.

Anche se qui mostriamo una sola dichia­ra­zione, biso­gna tenere pre­sente che biso­gna crearne: una per il roman e una per l’italico ³.

Real Web Type in Real Web Context #

Una volta che abbiamo impo­stato i nostri fogli di stile, per testare una font serve un qual­che tipo di testo stan­dard che ne metta in luce pregi e difetti.

Web Font Specimen fa esat­ta­mente que­sto. Possiamo sca­ri­care la pagina cam­pione in locale, impo­starla con le nostre font e vedere come si com­porta dal vivo, con i vari bro­w­ser ⁴.

Designing For The Switch #

Rendering a parte, uno dei pro­blemi prin­ci­pali nell’uso di @font-face è il peso, dovuto prin­ci­pal­mente alle tabelle di hin­ting molto estese.

Il Georgia, ad esem­pio, è quasi 300 KB, suf­fi­cienti rovi­nare il primo impatto per­ché alcuni bro­w­ser, come Opera e FireFox, pre­sen­te­ranno per un attimo la pagina senza la font cor­retta, il fami­ge­rato Flash of Unstyled Text (FOUT), men­tre altri, come il WebKit, aspet­te­ranno di aver sca­ri­cato tutta la font, non mostrando nes­sun testo durante l’operazione.

Da un punto di vista stret­ta­mente pro­ce­du­rale, non c’è nes­suna alter­na­tiva: la font dev’essere sca­ri­cata e fino a quando l’operazione non è ter­mi­nata le scelte pos­si­bili sono quelle viste prima ⁵.

Fighting the @font-face FOUT — Quicken the load time #

Tuttavia ci sono alcuni truc­chi uti­liz­za­bili. Il primo con­si­ste nel ridurre all’osso il file della font, eli­mi­nando tutto quello che non è stret­ta­mente indi­spen­sa­bile ⁶; il secondo con­si­ste nel cali­brare atten­ta­mente l’elenco delle font nel foglio di stile per mini­miz­zare il FOUT; poi lo pos­siamo zip­pare, gua­da­gnando fino al 40%; infine dovremo fare in modo che la font sca­ri­cata rimanga in cache.

L’arma nucleare tat­tica ⁷è però quella di for­zare il cari­ca­mento della font prima che la pagina venga mostrata, in modo da averla pronta quando serve.

Better font stacks #

Come accen­navo all’inizio, l’estensione dello stack delle font dichia­rate può essere usato per que­sto scopo (com­bat­tere il FOUT) ma anche sem­pli­ce­mente per usare com­bi­na­zione meno scontate.

La pre­messa fon­da­men­tale è che, in realtà, il bro­w­ser ha a dispo­si­zione molte più font di quelle di solito con­si­de­rate. Inoltre, è pos­si­bile indi­vi­duare delle com­bi­na­zioni accet­ta­bili per coprire i casi in cui la font ideale non è presente.

Questo lavo­rac­cio è già stato fatto e il cam­pio­na­rio in pdf alle­gato all’articolo citato è uti­lis­simo per pren­dere una deci­sione ⁸.

Real Fonts and Rendering: The New Elephant in the Room #

E ora veniamo al vero pro­blema emerso nei primi usi sul campo: il ren­de­ring delle font, dovuto ai com­por­ta­menti molto ete­ro­ge­nei dei motori di ren­de­ring in com­bi­na­zione con i diversi sistemi ope­ra­tivi. ⁹.

Browser Choice vs Font Rendering #

L’analisi di Zeldman difetta forse di pre­ci­sione, visto che si limita a con­sta­tare il pro­blema, anche se posso capirlo: i det­ta­gli sono un po’ da mal di testa. Comunque, guar­dando le cose con più atten­zione il pano­rama sem­bra meno preoccupante.

L’attuale sistema di ren­de­ring sotto Windows, il GDI, che for­ni­sce la base per l’anti-aliasing in ClearType, fun­ziona in modo ade­guato solo le font TrueType.

Le nuove ver­sioni dei bro­w­ser use­ranno però un’altro motore, il DirectWrite, più sofi­sti­cato, in grado di for­nire un ren­de­ring ade­guato anche per i PostScript e gli OpenType. Ci saranno ancora delle dif­fe­renze rispetto a Mac OS X ma saranno “solo” diversi.

In con­clu­sione

Dopo tante attese e false par­tenze l’uso di @font-face non è più solo una pos­si­bi­lità teo­rica. Tuttavia, anche se la voglia di usarlo sem­bra con­ta­giare tutti, allo stato attuale va usato con atten­zione: mi limi­te­rei alle tito­la­zioni; per i testi estesi ci vuole più prudenza.

Questi sono pro­blemi che ver­ranno comun­que risolti. Più impor­tanti, invece, i mes­saggi per chi si occupa di design web.

In primo luogo biso­gna supe­rare la fissa di fare in modo che una pagina si veda esat­ta­mente allo stesso modo ovun­que ¹⁰. Il fatto di avere più font a dispo­si­zione ha fatto emer­gere dif­fe­renze enormi fra le varie piat­ta­forme e, a com­pli­care ulte­rior­mente le cose, le piat­ta­forme stesse sono in con­ti­nua diver­si­fi­ca­zione¹¹. Inseguire l’assoluta omo­ge­neità è futile, però biso­gnerà essere più rigo­rosi nei test: le sor­prese del ren­de­ring sono sal­tate fuori in modo cla­mo­roso anche per­ché, a dispetto delle dichia­ra­zioni uffi­ciali, alcuni siti sono “usciti” con ver­sioni testate solo su Mac.

Inoltre e cosa più impor­tante, l’espansione dell’offerta di font uti­liz­za­bili signi­fica che è neces­sa­ria una mag­giore com­pe­tenza (tipo)grafica. Ci vor­ranno più gusto e più com­pe­tenza per la scelta e la com­bi­na­zione giuste.

Può darsi che quella dell’anno scorso sia stata solo una fiam­mata desti­nata a spe­gnersi e rima­nere dor­miente per altri anni ma non ci scom­met­te­rei: meglio prepararsi.

Volevo segna­lare Pagehand, nuovo word pro­ces­sor per Mac OS X, per­ché ha alcune fea­tu­res degne di nota.

Ma non basta Word?

Il primo punto a favore è l’uso del PDF come for­mato di file, non legan­doci quindi mani e piedi all’ennesimo for­mato proprietario.

Il secondo è l’occhio di riguardo con cui sono trat­tate le opzioni tipo­gra­fi­che e l’implementazione degli stili.

Certo, il con­fronto con altri word pro­ces­sor può essere impie­toso, eppure, mi sem­bra un’applicazione ben fatta, con un buon potenziale.

Siamo ancora all’inizio

È ovvio che potremmo pen­sare a innu­me­re­voli fea­tu­res da aggiun­gere, ma una mi sem­bra vera­mente man­cante, vista la filo­so­fia di base: non è pos­si­bile modi­fi­care pdf creati da altre applicazioni.

Non so molto del for­mato pdf per poter dire se sia una limi­ta­zione in qual­che modo giu­sti­fi­ca­bile, ma non credo. Speriamo che que­sta svi­sta venga cor­retta presto.

Segnalo altri due post che par­lano di Menlo e di Anonymous Pro, con un con­fronto molto meno raf­faz­zo­nato del mio.

Da qual­che giorno sto pro­vando Anonymous Pro ma con­ti­nua a sem­brarmi leg­gero nel peso stan­dard. Vedremo…

I link:

• Menlo / Vera Sans Mono Comparison;
• Anonymous Pro: a pro­gram­ming font with style.

Una delle cose che forse farà con­tento John Siracusa è che in Snow Leopard sarà dispo­ni­bile una nuova font mono­spa­ced, Menlo, una rivi­si­ta­zione dell’Andale Mono.

Il con­fronto fra i due carat­teri rivela che le dif­fe­renze si con­cen­trano sugli ele­menti più impor­tanti come la distin­zione fra O e 0, ad esem­pio. Credo anche che abbiano un sup­port migliore per i carat­teri tipo­gra­fici meno usati in pro­gram­ma­zione ma non sono sicuro.

Ma c’è un’altra font molto recente ed è l’Anonymous Pro. Forse per i miei gusti è un po’ leg­gera — soprat­tutto cal­co­lando che ulti­ma­mente uso Lucida Sans TypeWriter — ma vale la pena di pro­varla. Ecco uno screen­shot.

Segnalo anche un’imprecisione nell’articolo di Ars Technica: il Monaco è ancora incluso, almeno nelle vec­chie beta.

Bonus a chi capi­sce il signi­fi­cato del codice di esempio ;-)

Questo vec­chio arti­colo di Mark Boulton prende le mosse dalla tra­di­zio­nale scala tipo­gra­fica, ormai in uso da qual­che cen­ti­naio di anni.

In quell’articolo ne viene pro­po­sta una ver­sione per il web, tenendo conto delle pecu­lia­rità del medium. la scala è la seguente:

11px /16.5px — Body copy and lea­ding.
24px — Main hea­ding used as sec­tion hea­dings on the Homepage, Portfolio home­page and entries.
18px — Headings for jour­nal entries and port­fo­lio sub­hea­dings.
16px — All navi­ga­tio­nal and con­tent ter­tiary hea­dings.
13px — All other hea­ded elements.

Usando la scala di YUI ecco la mia ver­sione, pen­sata per usare come dimen­sione del testo nei para­grafi un valore di 13px/1.231em:

/* 24px */
h1 { font-size: 182%; }
/* 21px */
h2 { font-size: 161.6%; }
/* 18px */
h3 { font-size: 138.5%; }
/* 16px */
h4 { font-size: 123.1%; }

Curiosità: in entrambe le scale viene usato l’equivalente di 13px, che è l’unica dimen­sione — in punti — assente nella scala ori­gi­na­ria fra 6 e 14pt.

Nel ten­ta­tivo di capirci qual­cosa di più ho messo insieme una pagi­netta di rias­sunto sulla que­stione del ritmo ver­ti­cale. I com­menti sono graditissimi!

Questo arti­colo su Opera Dev mi dato lo sti­molo per scri­vere qual­che appunto un po’ più com­pleto sulle gri­glie per la base­line del testo (uso i ter­mini in inglese quando non cono­sco i cor­ri­spon­denti cor­retti in ita­liano), in par­ti­co­lare quando usiamo un fra­mework per i CSS come YUI.

La prime cose da deci­dere sono la font-size e line-height; con YUI, i valori sono: font-size: 13px e line-height: 1.231em (ovvero, 16px). In altri arti­coli ho visto appli­care un valore del 150%; con YUI avremmo 19.5px, che pos­siamo otte­nere, appros­si­mando, con 146.5% (19px) o 153.9% (20px), ma per que­sto arti­colo usiamo il default.

L’idea di base è che una volta scelto, que­sto valore sarà la nostra unità di base per cal­co­lare pad­ding, mar­gin e line-height, in modo che l’altezza com­ples­siva di un ele­mento sia sem­pre un suo mul­ti­plo di tale unità.

Paragrafi e altri block elements

Per ele­menti come p basta com­pen­sare il valore di 1em asse­gnato di default dai bro­w­ser ai margini:

p {
  margin-top: 16px;
  margin-bottom: 16px;
}

Liste

Per le liste dob­biamo deci­dere, even­tual­mente caso per caso, se spe­ci­fi­care il trat­ta­mento per ogni sin­gola riga, e quindi rica­dere negli esempi visti prima, o con­si­de­rare la lista come blocco unico; in que­sto caso basterà spe­ci­fi­care margin-bottom.

Immagini e callouts

Per gli altri ele­menti, dob­biamo deci­dere in base alla pos­si­bi­lità o meno di sapere in anti­cipo l’ingombro ver­ti­cale: di un’immagine pos­siamo sta­bi­lire che dovrà essere alta, ad esem­pio, 80px (ovvero, un mul­ti­plo di 16) e quindi essere certi che non rom­perà il ritmo ver­ti­cale; per gli ele­menti varia­bili come bloc­chi di testo in cal­lout, se gli ele­menti all’interno rispet­tano già la misura stan­dard, dob­biamo solo accer­tarci che la somma di mar­gin, pad­ding e bor­der siano anch’essa un multiplo:

.callout {
  border: 1px solid #ddd;
  padding: 7px 10px;
  margin-bottom: 16px;
}

Infatti: bor­der top + pad­ding top + pad­ding bot­tom + bor­der bot­tom = 16px.

Nel caso delle imma­gini, se vogliamo anche cal­co­lare la pos­si­bi­lità che l’utente possa ridi­men­sio­nare il testo, pos­siamo spe­ci­fi­care le dimen­sioni dell’immagine in em, in que­sto caso, 5em.

Quindi, quando le dimen­sioni del testo non variano basta lavo­rare sui para­me­tri del box model: mar­gin, bor­der e padding.

Variazioni su line-height

Invece, tutte le volte che cam­biamo font-size si pone il pro­blema di cosa fare con il valore di line-height. Su OperaDev quest’ultimo non viene nem­meno variato e si lavora solo sul box model; nell’arti­colo di A List Apart, con­si­gliano di usare sem­pli­ce­mente dei mul­ti­pli del valore di base per i titoli ma non dicono nulla sulla pos­si­bi­lità di avere dei cal­lout in cui la dimen­sioni del testo è minore di quel valore; in 24 Ways, il valore di line-height per i titoli viene otte­nuto divi­dendo il valore di base per font-size e appli­cando lo stesso metodo anche ai cal­lout in modo da otte­nere sem­pre una gri­glia omo­ge­nea — tut­ta­via non dicono nulla sul pro­blema di una line-height troppo pic­cola quando i titoli scor­rono su più righe; infine, Mark Boulton pro­pone un miglio­ra­mento per i cal­lout ma pur­troppo non dice nulla sui titoli.

Che fare? Questi sono i valori che ho usato per il file di esem­pio di gri­glia per ritmo ver­ti­cale:

h1 {
    font-size: 24px;
    line-height: 0.6667em;
    margin-bottom: 0.6667em;
    margin-top: 1.3334em;
}
h2 {
    font-size: 19px;
    line-height: 1.2631em;
    margin-bottom: 0.8421em;
    margin-top: 0.8421em;
}
h3 {
    font-size: 18px;
    line-height: 0.8889em;
    margin-bottom: 0.8889em;
    margin-top: 0.7778em;
}

In pra­tica ho usato la divi­sione, tranne che per l’h2, dove, a causa del testo che scorre su più righe, il valore di line-height era troppo basso e quindi l’ho mol­ti­pli­cato per 1,5, otte­nendo un box di 48px.

Considerazioni simili pos­sono essere fatte per bloc­chi di testo con un valore di font-size infe­riore a quello base, come nei cal­lout: pos­siamo fare in modo che ogni riga stia nella gri­glia stan­dard o fare in modo che sia pro­por­zio­nale alle dimen­sioni del testo nel callout.

Nel primo caso line-height viene incre­men­tato tra­mite la for­mula: line-height stan­dard / dimen­sione testo cal­lout. Nel secondo caso dob­biamo prima deci­dere il rap­porto, fra numero di righe del testo prin­ci­pale e quello del cal­lout e poi fare qual­che cal­colo. Se vogliamo che ogni quat­tro righe di testo “stan­dard” ci siano cin­que righe di cal­lout, allora il valore di line-height sarà: line-height stan­dard * 4 / 5, ovvero, 12.8 px. Tuttavia va ricor­dato che dovremo anche aggiu­stare (a occhio) il valore di margin-top.

Strumenti utili

Se con­si­de­riamo ogni caso sin­go­lar­mente, gli accor­gi­menti descritti non sono dif­fi­cili da seguire ma quando lavo­riamo su una pagina nel suo insieme può venire utile qual­che strumento.

Per FireFox, oltre ai clas­sici come Firebug e Web Developer, ho tro­vato utile Gridfox.

Altri post sull’argomento

• Ritmo ver­ti­cale nelle pagine web
• Ritmo ver­ti­cale con le note a margine