Come semplificare la vita a designer e developer
È del 2016 l’annuncio di Microsoft, Google, Apple e Adobe di aver creato un nuovo formato di webfont, gli OpenType Font Variations (più comunemente noti come Variable Fonts), ad oggi ancora non largamente diffusi nel web, pur potendo offrire numerosi vantaggi sia ai designer che ai developer.
Nel frattempo Google si prepara ad integrare una fetta sempre maggiore dei suoi webfont gratuiti. Sarà questa la svolta che li farà decollare come meritano?
Ma vediamo con ordine cosa sono i Variable Fonts e perché possono essere così cruciali per chi si occupa di sviluppo web.
Una buona tipografia non solo impatta sull’interfaccia grafica di un progetto web (e di questo sicuramente possono rendersene conto tutti coloro che hanno un minimo di senso estetico), ma soprattutto ne migliora la user experience. A differenza della carta stampata però, dove un designer può affrontare un progetto scegliendo tra una miriade di famiglie di font diversi, pesi, stili (in pratica possibilità illimitate e pochi vincoli), un front-end designer ha un ventaglio di scelte molto più limitato.
Questo dipende da diversi fattori, innanzitutto da quello tecnologico.
Per renderizzare a video un font è necessario che l’utente, navigando su una pagina, ne scarichi il relativo file: tecnicamente degli OpenType , ovvero un file contenente tutti i caratteri di un font vettorializzati. Questo vale per ogni singolo peso della stessa famiglia di font e anche per ogni stile, il che aumenta non di poco la latenza ed il tempo di rendering della pagina. L’uso di caratteri normali, parole in grassetto e parole in corsivo in una sola pagina può aumentare anche di 500KB il peso della stessa. Ci si trova, quindi, davanti ad una scelta che impone una rinuncia nell’uso di svariati pesi di uno stesso font in favore dell’ottimizzazione del css prodotto.
E se volessimo salvare capra e cavoli?
Annunciati come dei supereroi, arrivano in nostro aiuto i Variable Fonts!
Un Font Variabile è un file che incorpora tutte le varianti di un font, includendo pesi, stili, e numerose possibili altre variabili, in un unico file.
A livello tecnico la prima cosa che salta all’occhio è che il browser non dovrà caricare diversi file per ogni caratteristica del font da richiamare, cosa che già da sola basterebbe a farci esclamare: wooow!
Ma - udite udite - la caratteristica più importante per un front-end developer, è che, finalmente, può usare il suo font preferito alterandone le caratteristiche a seconda dell’esigenza! Questo per la struttura stessa del variable font.
Per capire di cosa parliamo, vediamo come è fatto un font variabile.
In buona sostanza il type designer crea un font definendone le caratteristiche (peso, serif/non-serif, italic, etc). Per ognuna di queste proprietà del font crea un asse variabile e ne fissa dei master point, ovvero un punto massimo ed uno minimo. Il font, dunque, potrà essere utilizzato scegliendo un valore compreso nel suddetto asse, tra i suoi master point.
Facciamo un esempio concreto. Abbiamo un font che per l’ asse weight ha come master point 300 e 900. Potremo usare questo font assegnando alla proprietà font-weight un qualsiasi valore compreso tra 300 e 900, richiamando un solo file nel nostro progetto.
Attualmente gli assi standard sono:
Il type designer potrà anche decidere di creare nuovi assi variabili e dare spazio alla sua creatività (ad esempio l’asse delle grazie di un carattere che consentirà di rendere un carattere con o senza-serif).
Ovviamente più assi sono definiti, più le combinazioni tra le variabili aumentano e di conseguenza le possibilità di usare quel font in modo avanzato!
E Google come si colloca in questo discorso?
Il colosso della Silicon Valley ha finalmente iniziato ad aprire le porte ai font variabili, ma in che modo possono essere usati, e soprattutto, a che livello di implementazione siamo arrivati? Nella sezione dei Google webfonts è possibile spuntare l’opzione ‘ only variable fonts ’.
Ed ecco apparire la famosa lista di font tanto ambiti. Certo, al momento quelli disponibili presentano un solo asse variabile - probabilmente una scelta strategica di Google per facilitarne l’uso, dato il suo ampio target che include anche i meno esperti - quasi sempre quello del peso del carattere.
Facciamo un esempio pratico. Il font “ Oswald” ha nell’asse del peso due master point:
Decidiamo di usare il thin per i paragrafi e di scegliere poi tre misure intermedie nell’asse variabile del peso per i tag h1, h2 ed h3.
Ci sono due modi di incorporare i Google Variable Fonts richiamando le API di Google Fonts:
<link href="https://fonts.googleapis.com/css2?family=Oswald:wght@200;350;450;600&display=swap" rel="stylesheet">e definendone il css in questo modo:
h1 {
font-weight: 600;
}
...
p {
font-weight: 200;
}
<link href="https://fonts.googleapis.com/css2?family=Oswald:wght@200..700&display=swap" rel="stylesheet">e definendone il css così:
h1 {
font-variation-settings:"wght" 690;
}
…
p {
font-variation-settings:"wght" 400;
}
Quello che avremo è quanto riportato nell’esempio seguente:
Immaginate ora cosa può accadere per un font tra le cui variabili ci sono le grazie, o ancora un font calligrafico che ha tra le variabili la rotondità del tratto…
Qualche esempio?
Insomma, avendo un po’ di fantasia c’è da sbizzarrirsi e soprattutto senza impazzire!
Ma come la mettiamo con la compatibilità? Indubbiamente c’è ancora tanta strada da fare, ma siamo sicuri che l’apertura di Google ai font variabili sia il segnale che stavamo aspettando che fa ben sperare nella loro diffusione su larga scala.
Sono stati fatti grossi passi in avanti rispetto al 2016, ma non siamo ancora arrivati ad una percentuale piena di compatibilità.
Per questo motivo ci sono degli escamotage da adottare per assicurarci la visibilità sui vecchi browser, ad esempio, nel css possiamo usare alla vecchia maniera un font simile a quello variabile scelto:
body {
font-family: 'Oswald', sans-serif;
}
ed aggiungere questa regola per i browser moderni:
@supports (font-variation-settings: normal) {
body {
font-family: 'Oswald Variable';
}
}
In questo modo avremo dato una chance al nostro sito di apparire come dovrebbe e al browser di non appesantirsi nel caricare risorse inutili quando non sono necessarie.
Concludendo, certi che “ Sempre in movimento è il futuro ” (cit. Yoda), possiamo affermare che sicuramente si tratta di un futuro migliore per i front-end developer!