Questa è la traduzione dell'articolo Fluid Grids di Ethan Marcotte pubblicato originariamente su A List Apart il 03 Marzo 2009. La traduzione viene qui presentata con il consenso dell'editore e dell'autore.
Nota: nella prima parte saranno affrontate le basi teoriche (uso e comportamento delle unità di misura relative nei CSS), nella seconda si procederà all'analisi delle griglie fluide e dei layout.
L'anno scorso ho lavorato al redesign di un sito molto ricco di contenuti. I requisiti del design erano piuttosto leggeri: il cliente ci ha chiesto di mantenere il logo dell'organizzazione e di migliorare la tipografia aumentando al contempo la leggibilità. Così, nella fase iniziale del progetto, abbiamo speso un po' di tempo per pianificare una griglia ben definita per una libreria di moduli di contenuto.
Negli anni scorsi, questo approccio è diventato più diffuso. Grazie alla spinta di personaggi come Mark Boulton, Khoi Vinh e altri, abbiamo assistito ad un rinnovato interesse per le griglie tipografiche e per i modi in cui impiegarle sul web. L'idea è stata in effetti di grande successo: sono comparsi milioni di framework e librerie CSS, con ottimi strumenti di assistenza e supporto a fare da complemento. Ciascuno di questi framework consente al designer di costruire in maniera semplice design basati sulle griglie. Perché no, dunque? Dopo pochi minuti di ragionamento, i benefici sono apparsi chiari: i designer hanno ora a disposizione un framework razionale e strutturato per organizzare il contenuto e gli utenti ottengono siti ben organizzati e leggibili.
Tuttavia, il nostro cliente aveva un'ulteriore richiesta: il design doveva essere fluido e ridimensionabile insieme alla finestra del browser. Normalmente una cosa del genere avrebbe dovuto farmi gioire. I layout fluidi sono una comodità sottovalutata nel web design. Mettono il controllo del nostro design nelle mani dell'utente e delle sue abitudini di navigazione. Allo stesso tempo, però, questi layout non hanno catturato come ci si potrebbe aspettare l'immaginazione dei web designer.
Risoluzione minima dello schermo: una piccola bugia
Invece di esplorare i benefici di un web design flessibile, noi ci affidiamo ad una piccola innocente bugia: la "risoluzione minima dello schermo". Queste tre parole contengono una speciale forza magica, sotto la cui copertura continuiamo a produrre meccanicamente layout a larghezza fissa uno dopo l'altro, magari aggiustando un design a distanza di qualche anno e aumentando la larghezza una volta che siamo certi che così facendo siamo al riparo da problemi.
La "risoluzione minima dello schermo" ci fa creare design per un insieme di utenti che vedono il nostro lavoro come Dio e Photoshop comandano. Questi utenti navigano sempre con una finestra massimizzata di 1024x768px, e mai usano, per dire, un laptop OLPC, mai navigano sul web usando un monitor più vecchio di quattro anni. Se un utente non ha questi i requisiti della "risoluzione minima dello schermo", beh, per lui c'è sempre la scrollbar del browser...
Certo, mentre lavoravo al codice per quel sito non avevo l'opportunità di dilungarmi in una diatriba sui mali del design a larghezza fissa. Invece ho dovuto confrontarmi con questo semplice fatto: mentre noi avevamo progettato una griglia piuttosto complessa per andare incontro alle esigenze del nostro cliente riguardo ai contenuti, il cliente e gli utenti del sito richiedevano un layout fluido. Ed ecco la questione complicata: come creare una griglia fluida?
Come vedremo, è solo una questione di contesto.
Devo davvero ringraziare IE per tutto questo?
Di fronte a un problema insormontabile ho fatto quello che so fare meglio: evitarlo. Ho messo temporaneamente da parte la questione relativa al come far comportare una griglia nel contesto di un layout non fisso e ho messo sotto forma di codice le cose che sapevo: prima gli stili per i colori e gli sfondi, poi quelli per la tipografia.
Conoscete sicuramente il problema di Internet Explorer rispetto alla sua incapacità di ridimensionare i font impostati in pixel (sarebbe meglio parlare di rifiuto). Impostate un paragrafo in Georgia 16px: non importa quanto l'utente provi ad aumentare e diminuire le dimensioni, rimarranno sempre di 16px su Internet Explorer. IE7 e IE8 consentono all'utente di fare lo zoom dell'intera pagina, ma ridimensionare il testo settato in pixel è cosa proibita su IE. Così, per dare all'utente la massima flessibilità possibile, i designer più attenti agli standard hanno preferito rinunciare del tutto ai pixel e si sono affidati all'uso di unità di misura relative, si tratti di keywords, percentuali o em (quella che preferisco).
Se avete lavorato qualche volta con un unità relative come gli em, sapete che tutto dipende dal contesto: in altre parole, la misura effettiva dell'em di un elemento è calcolata relativamente alla font-size del suo elemento parente. Per esempio, diciamo che stiamo lavorando sul seguente design:
Niente di particolare: alcuni paragrafi definiti in Helvetica 16px, una lista non ordinata in 14px, un titolo h1 in Georgia 24px. Interessante, vero?
La cosa doppiamente interessante è che una semplice regola ci consente di ottenere più o meno tutto ciò (esempio):
body {
font: normal 100% Helvetica, Arial, sans-serif;
}
Con una font-size del 100%, tutti gli elementi nella nostra pagina sono dimensionati relativamente alla dimensione del testo di default del browser, che nella maggior parte dei casi è di 16px. E grazie agli stili di default del browser, l'h1 apparirà grande e in grassetto: ma sempre in Helvetica e troppo grande. Così, mentre è facile affidarsi ad una font-family per correggere il problema del font Helvetica sul titolo, come impostiamo il testo a 24px? Oppure, come riduciamo a 14px la dimensione del testo della lista?
Con gli em si può fare facilmente. Prendiamo la dimensione in pixel dell'elemento che ci interessa formattare e la dividiamo per la font-size del suo elemento contenitore (ovvero il suo contesto). Otterremo a quel punto la font-size desiderata espressa in em. Detto in sintesi:
elemento ÷ contesto = risultato
Ammettendo che la dimensione di default del testo nel browser è di 16px, possiamo ottenere da questa formula il valore desiderato. Così, nell'esempio, dividiamo il valore dell'h1 (24px) per la dimensione del testo del suo contenitore (l'elemento body, ovvero 16px):
24 ÷ 16 = 1.5
Così il titolo è grande 1.5 volte la dimensione di default del body, ovvero 1.5em. Possiamo allora inserire questa regola nel nostro CSS:
h1 {
font-family: Georgia, serif;
font-size: 1.5em; /* 24px / 16px = 1.5em */
}
Per dimensionare la lista all'equivalente in em di 14px possiamo usare la stessa formula. Ammettendo, di nuovo, che la misura di default del body è di 16px, facciamo la divisione:
14 ÷ 16 = 0.875
Otteniamo un valore di 0.875em. Mettiamo di nuovo tutto nel CSS:
ul {
font-size: 0.875em; /* 14px / 16px = 0.875em */
}
Con queste due regole la nostra pagina di esempio è molto più simile allo schema da cui siamo partiti, e con qualche rifinitura sarà praticamente perfetta al pixel. Tutto ciò grazie alla formula elemento ÷ contesto = risultato.
Così, dopo un po' di ore spese a rifinire le dimensioni relative nei fogli di stile per il nostro cliente, ho capito di essere arrivato alla risposta che cercavo. Se possiamo trattare le dimensioni dei font non come pixel ma come proporzioni misurate rispetto ad un contenitore, possiamo fare lo stesso con i differenti elementi sparsi sulla nostra griglia.
Vedremo come ottenere il risultato desiderato nella seconda parte dell'articolo online tra una settimana.
Dopo tutto non è "Il pixel d'oro"
Come nel caso analizzato nella prima parte iniziamo da un layout molto semplice:
Certo, è un "design" piuttosto modesto. Ma quei semplici stili sono in realtà sparsi su una griglia ben definita. Si tratta, per la precisione, di una griglia con 7 colonne ciascuna larga 124px; le colonne sono separate di 20px. Il totale della larghezza ammonta dunque a 988px. Ma dobbiamo dimenticarci di questi benedetti pixel! Ricordate? Ora è il momento delle proporzioni! Trasformiamo tutto in qualcosa di fluido:
Per iniziare, trattiamo il nostro schema di base come qualunque altro, fisso o fluido: prima di mettere mano al codice diamo un'occhiata al design e valutiamo le differenti aree di contenuto. Per fortuna si tratta di poca roba:
Sul livello più alto abbiamo un titolo, un'area del contenuto che si espande per 6 colonne e alcune informazioni di contesto sulla colonna sinistra. Da questo diagramma possiamo tirare fuori un markup di base che si adatti al nostro repertorio di contenuti, sia semanticamente sia strutturalmente:
<div id="page">
<h1>The Ratio Revolution Will Not Be Televised</h1>
<div class="entry">
<h2>Anyone else tired of Helvetica?</h2>
<h3 class="info">A <a href="#">Blog</a> Entry:</h3>
<div class="content">
<div class="main">
<p>Main content goes here. Lorem ipsum etc., etc.</p>
</div><!-- /end .main -->
<div class="meta">
<p>Posted on etc., etc.</p>
</div><!-- /end .meta -->
</div><!-- /end .content -->
</div><!-- /end .entry -->
</div><!-- /end #page -->
Applicando qualche regola per la tipografia otteniamo un buon punto di partenza. Tuttavia, il container #page non ha alcun limite, così il contenuto si espanderà andando a riempire per intero la larghezza della finestra del browser. Proviamo a bloccare e accorciare quelle lunghe linee:
#page {
margin: 40px auto;
padding: 0 1em;
max-width: 61.75em; /* 988px / 16px = 61.75em */
}
Abbiamo usato margini e padding per dare un po' di 'respiro' al nostro design e stabilire una separazione tra esso e i lati della finestra. Ma nell'ultima riga della regola CSS appena vista, usiamo anche una variante della nostra formula della font-size per definire la larghezza massima. Dividendo la larghezza globale (988px) per la font-size di base (16px), possiamo impostare una max-width in em che si avvicini alla larghezza espressa in pixel del nostro layout: ciò impedirà alla pagina di superare la larghezza ideale di 988px. Ma poiché abbiamo usato gli em per impostare questo limite massimo, la larghezza massima (max-width) scalerà se l'utente aumenta la dimensione del testo. È un piccolo trucco che funziona anche su Internet Explorer se si applica una piccola patch al CSS.
Così, con il nostro design adeguatamente limitato, iniziamo a lavorare sui singoli elementi. Cominciamo con il titolo della pagina. Nello schema esso occupa 5 colonne della griglia con 4 separatori, per una larghezza totale di 700px. Viene anche spostato dal lato sinistro della pagina per uno spazio corrispondente a 1 colonna e 2 separatori, in tutto 144px. Se stessimo lavorando su un design a larghezza fissa, tutto sarebbe estremamente semplice:
h1 {
margin-left: 144px;
width: 700px;
}
Ma poiché stiamo lavorando in un contesto che è fluido, le unità di misura fisse, come i pixel, non vanno esattamente bene. Mentre lavoravo sul dimensionamento del testo in unità relative, ecco cosa mi ha colpito: ogni aspetto della griglia (e gli elementi che su di essa vengono disposti) può essere espresso come una proporzione relativa al suo contenitore. In altre parole, come nell'esercizio sul ridimensionamento del testo visto nella prima parte, stiamo considerando non solo la misura desiderata dell'elemento, ma anche la relazione tra quella misura e il contenitore dell'elemento. Ciò consente di convertire le larghezze espresse in pixel nel nostro design in percentuali e di mantenere intatte le proporzioni della griglia quando viene ridimensionata.
In poche parole, otteniamo una griglia fluida.
Tutto ciò che è vecchio è nuovo
Da dove iniziamo?
elemento ÷ contesto = risultato
Esatto: ritorna la nostra cara e amata formula per il dimensionamento del testo. Possiamo usare la stessa analisi delle proporzioni per trasformare larghezze di colonne basate su pixel in misure basate su percentuali, flessibili. Stiamo così lavorando su un valore di 700px del titolo, ma esso è contenuto in un elemento largo 988px:
Dividiamo semplicemente 700px per 988px, così:
700 ÷ 988 = 0.7085
Ed ecco: 0.7085 corrisponde al 70.85%, una larghezza che possiamo così assegnare al titolo nel nostro CSS:
h1 {
width: 70.85%; /* 700px / 988px = 0.7085 */
}
Possiamo fare lo stesso per il margine di 144px? Certo:
144 ÷ 988 = 0.14575
Ancora una volta, possiamo prendere 0.14575, o 14.575%, e aggiungerlo direttamente alla regola nel CSS come valore per il margin-left del titolo:
h1 {
margin-left: 14.575%; /* 144px / 988px = 0.14575 */
width: 70.85%; /* 700px / 988px = 0.7085 */
}
E voilà, ecco l'esempio. Misurando il margine e la larghezza del titolo relativamente al suo contenitore, abbiamo con successo tradotto i rapporti della nostra griglia in percentuali adatte ai CSS. Le proporzioni del titolo rimarranno sempre intatte, anche se esso si espande per riempire la dimensione della finestra del browser.
Possiamo anche eseguire la stessa semplice divisione per aggiustare l'area del contenuto principale. Nel nostro schema si estende per 844px, con 124px di contenuto accessorio sulla sinistra. Ecco il calcolo:
844 ÷ 988 = 0.85425
E questo il calcolo per la colonna sinistra:
124 ÷ 988 = 0.12551
Queste due rapide divisioni ci restituiscono dei valori che possiamo da subito inserire nel nostro CSS, rifinendo ancora meglio il layout:
.entry h2,
.entry .content {
float: right;
width: 85.425%; /* 844px / 988px = 0.85425 */
}
.entry .info {
float: left;
width: 12.551%; /* 124px / 988px = 0.12551 */
}
E così, la nostra griglia fluida prende sempre più forma (esempio).
Cambiare il contesto
Così abbiamo aggiustato le macro-aree di contenuto. Dobbiamo però ancora toccare le aree interne. Al momento, l'area per il post del blog e quella per le sue informazioni di contesto (data, numero di commenti, tag) occupano la larghezza intera dell'area e sono sistemato una sopra l'altra. Ma nel nostro schema iniziale, l'area del post si espande per 5 colonne, mentre le informazioni accessorie sono posizionate sulla colonna destra.
I lettori più attenti avranno notato che, per come è attualmente disegnato, il corpo dell'area del post ha la stessa larghezza del titolo (700px), e che la colonna destra ha la stessa larghezza di quella sinistra (124px). Così, mentre stiamo lavorando con delle dimensioni su cui abbiamo già lavorato con i nostri calcoli, non possiamo riusare le stesse formule: il contesto è cambiato.
Mentre prima abbiamo calcolato percentuali relative alla larghezza di 998px dell'elemento #page, ora stiamo lavorando nel contesto di .entry .content, che è più piccolo. Come risultato, dobbiamo ridefinire il nostro contesto e lavorare sulla larghezza di .entry .content come punto di riferimento. Così, per definire la larghezza in percentuale dell'area del post, prendiamo la larghezza di 700px e la dividiamo per 844px:
700 ÷ 844 = 0.82938
Per la colonna di 124px sulla destra, possiamo usare lo stesso punto di riferimento:
124 ÷ 844 = 0.14692
Possiamo ora prendere le misure risultanti e inserirle nel CSS:
.entry .main {
float: left;
width: 82.938%; /* 700px / 844px = 0.82938 */
}
.entry .meta {
float: right;
width: 14.692%; /* 124px / 844px = 0.14692 */
}
Così abbiamo portato a termine il nostro lavoro (esempio).
Una nota sull'arrotondamento
Come potete intuire dalla mancanza di hack particolari, ho avuto pochi problemi di compatibilità cross-browser con questa tecnica. Raccomando la lettura dell'eccellente articolo di John Resig Sub-Pixel Problems in CSS. Spiega come i vari browser gestiscono le larghezze basate su percentuali e i meccanismi con cui essi aggiustano le misure.
Come spiega John nel suo articolo, se i moderni browser si trovano davanti quattro elementi larghi il 25% all'interno di un contenitore di 50px, non possono di fatto rendere gli elementi con la dimensione di 12.5px; invece, la maggior parte faranno un arrotondamento verso l'alto o verso il basso per adattare al meglio le colonne al layout. Internet Explorer si limiterà ad arrotondare i valori di sub-pixel, cosa che rovina il layout.
Se state lavorando con margini sufficienti nella vostra griglia, ciò non dovrebbe costituire un problema. Ma se IE rovina tutto, basta ridurre di un pixel il valore della parte elemento nella nostra formula per evitare guai. Così, dunque, se la nostra colonna sinistra è troppo larga per Internet Explorer, possiamo cambiare il calcolo da
124 ÷ 988 = 0.12551
a
123 ÷ 988 = 0.12449
Mettete 12.449% in un foglio di stile ad hoc per IE con i commenti condizionali e il layout dovrebbe essere a posto.
Una griglia per tutte le stagioni
Quanto visto è solo un punto di partenza: ci sono miriadi di altre sfide che un web designer a cui piace lavorare con il fluido deve affrontare, la maggior parte delle quali nasce quando si ha la necessità di inserire contenuti a larghezza fissa (immagini, Flash, etc.). Ho fatto un po' di esperimenti sul mio blog, ma altre, migliori, soluzioni devono ancora arrivare.
Infine, non pretendo che il design sia cosa semplice, sia esso fisso o fluido. Ma pensando a quanto abbiamo ottenuto negli anni passati (fare fuori le tabelle, promuovere l'uso degli standard, richiedere un migliore supporto per gli standard ai produttori di browser), mi auguro che possiamo avere altrettanta fortuna nel liberarci dalla dipendenza dalla "risoluzione minima dello schermo". Spero che le griglie fluide abbiano stimolato la vostra immaginazione e mi auguro che questa tecnica possa essere migliorata.
Letture
Come si sarà capito dalla parte iniziale di questo articolo, due mie passioni sono il design fluido e le griglie ben definite. Entrambe queste passioni sono state alimentate dalla seguenti letture, anche se si tratta di una lista non esaustiva:
- John Allsopp, A Dao of Web Design
- Mark Boulton, Feeling your way around grids
- David Emery, More Width
- Molly Holzschlag, Thinking Outside the Grid
- Jeremy Keith, The unpushed envelope
- Jeffrey Zeldman, Rules-based design
Per concludere, alla fine di una conferenza che ho tenuto lo scorso mese di agosto sulla progettazione di griglie fluide, qualcuno mi ha segnalato Fluid 960 Grid. Se usate già un framework CSS come 960 Grid System, potrebbe interessarvi.
