Progressive enhancement con i CSS

Questa è la traduzione dell'articolo Progressive Enhancement with CSS di Aaron Gustafson pubblicato originariamente su A List Apart il 21 Ottobre 2008. La traduzione viene qui presentata con il consenso dell'editore e dell'autore.

Nel precedente articolo di questa serie abbiamo parlato del concetto di progressive enhancement; ora possiamo iniziare a vedere come funziona e come usarlo. Ci sono molti modi per per integrare il progressive enhancement nel nostro lavoro usando i CSS: questo articolo affronterà alcuni dei principali
e vi darà una traccia su altri modi con cui migliorare in maniera progressiva il vostro sito.

Organizzazione dei fogli di stile

Molti web designer e sviluppatori non pensano molto ai vari sistemi con cui incorporare fogli di stile nei loro documenti, ma si tratta di una vera arte. Con i metodi giusti potrete immediatamente guadagnare molti dei benefici del progressive enhancement.

Usare fogli di stile multipli

Sono molti i benefici che si possono trarre separando nel modo giusto gli stili. Ovviamente, fogli di stile che siano lunghi più di 1500 righe sono un po' difficili da mantenere e spezzarli in più fogli di stile può migliorare tutto il flusso di lavoro (e la vostra sanità mentale). Un altro beneficio spesso non considerato è che la separazione può aiutarvi ad ottenere una maggiore consistenza della presentazione su tutti i tipi di media a cui vi state indirizzando.

Prendete in considerazione l'idea di prendere il vostro CSS principale, main.css, che contiene tutte le regole di stile del vostro sito e spezzarlo in più fogli di stile che contengano le regole tipografiche, quelle sul layout e le informazioni sul colore. Assegnate dei nome adeguati: type.css, layout.css, color.css.

Figura 1 - Come un singolo foglio di stile viene separato in CSS multipli e contestuali

Una volta che lo avrete fatto, potrete usare qualche semplice trucco per fornire un'esperienza di "basso livello" e minimale ai browser più vecchi (come Internet Explorer 5/Mac) e a quei browser che non hanno un solido supporto dei layout CSS. Come? Bene, tutto sta nel modo in cui incorporate i CSS nella pagina. Diciamo di iniziare da un file main.css incluso con l'elemento link:

<link rel="stylesheet" type="text/css" href="main.css" />
  

Per prima cosa lo spezzeremo in tre fogli di stile:

<link rel="stylesheet" type="text/css" href="type.css" />
<link rel="stylesheet" type="text/css" href="layout.css" />
<link rel="stylesheet" type="text/css" href="color.css" />

In passato, molti di noi hanno usato il valore di media type "screen, projection" per far sì che chi usava Netscape 4 potesse fruire degli stili per il layout. Prima di parlare di questa soluzione però, pensiamo ai tipi di media alternativi.

Lavorare con i tipi di media alternativi

Dal momento che la distribuzione di contenuti è il principale obiettivo del progressive enhancement e noi vogliamo fornire un'esperienza "migliorata" a tutti i dispositivi che sono in grado di supportarla, dovremmo iniziare a pensare oltre il browser; dovremmo di fatto pensare alla stampa e ai dispositivi mobili.

Purtroppo, il mercato dei dispositivi mobili è ancora frammentato e immaturo. Di conseguenza una discussione sui pro e i contro nella gestione di questi dispositivi secondo i dettami del progressive enhancement occuperebbe diversi articoli, se non un intero libro. Ma non disperate: la cose stanno iniziando a cambiare nel mondo del mobile e alcune persone di valore hanno iniziato a mettere insieme utili risorse. Qui però, per una questione di tempo e di sanità mentale, parleremo solo della stampa.

Ora, normalmente, aggiungeremmo un foglio di stile per la stampa con un altro elemento link:

<link rel="stylesheet" type="text/css" media="print" 
href="print.css" />

In genere, questo foglio di stile conterrà tutte le regole relative alla stampa, incluse le regole tipografiche e per il colore. Nel caso della tipografia in particolare, le regole del nostro foglio di stile rispecchieranno per lo più quelle del foglio di stile principale. In altre parole avremo una duplicazione.

Ecco allora dove la separazione dei fogli di stile per la tipografia e per il colore da quello per il layout diventa un'eccellente risorsa: non abbiamo più bisogno di regole per il layout nel foglio di stile per la stampa. Possiamo poi usare un'altra piccola tecnica di organizzazione per migliorare la scalabilità del nostro sito e nascondere certi stili per il layout da alcuni browser problematici.

Iniziamo rivedendo i nostri fogli di stile. Considerate il seguente codice:

<link rel="stylesheet" type="text/css" href="type.css" />
<link rel="stylesheet" type="text/css" href="layout.css" />
<link rel="stylesheet" type="text/css" href="color.css" />

Ora, dal momento che non abbiamo dichiarato alcun tipo di media, Netscape 4.x leggerà tutti gli stili presenti nei 3 fogli di stile, ma noi possiamo usare la sua scarsa comprensione dei CSS contro di lui e fornire un'ulteriore organizzazione per le nostre regole spostando tutte gli stili contenuti in layout.css in un foglio di stile tutto nuovo chiamato screen.css. Infine, aggiorniamo i contenuti di layout.css per importare screen.css e così Netscape 4.x e i suoi simili non potranno leggere quel CSS dal momento che non riconoscono la direttiva @import:

@import 'screen.css';

Possiamo ancora migliorare le cose. Dovremmo dichiarare a quale media è destinato quel foglio di stile e lo faremo aggiungendo un media type alla dichiarazione @import:

@import 'screen.css' screen;

Il problema è che IE7 e versioni inferiori non interpretano questa sintassi e ignoreranno il foglio di stile, ma se volete fornire questi stili anche a quei browser (cosa che quasi sicuramente vorrete), potete riuscirci facilmente usando i commenti condizionali di cui parleremo più avanti. Quelli di voi che hanno l'occhio di un'aquila avranno anche notato l'uso dell'apice semplice ( ' ) invece dei doppi apici ( " ) intorno al nome del CSS. È un piccolo trucco per far sì che Internet Explorer 5 /Mac ignori il foglio di stile. E dal momento che la resa dei layout CSS da parte di questo browser è molto problematica (specie per la gestione di float e posizionamenti) è del tutto accettabile trattarlo in questo modo. Dopo tutto, il browser continuerà a ricevere le informazioni di stile relative a tipografia e colore, il che non è poco.

Usando la stessa tecnica, possiamo importare il nostro foglio di stile print.css (che contiene, si capisce, le regole relative al layout di stampa):

@import 'screen.css' screen;
@import 'print.css' print;

Ora non solo abbiamo dei fogli di stile ben organizzati, abbiamo anche un mezzo efficace per migliorare in maniera progressiva il nostro sito.

Figura 2 - Le ralazioni tra i fogli di stile multipli e il metodo con cui sono applicati al documento

Cosa fare con IE6?

Per molti Internet Explorer 6 è un po' come Netscape 4.x: tutti vorrebbero che sparisse dalla circolazione.

Eviteremo la solita litania sui problemi di IE6; problemi che sono del resto ben documentati e, onestamente, non così difficili da superare. Inoltre, l'adozione di IE7 è stata particolarmente rapida (specie nel mercato consumer) e IE8 è già alla seconda beta: significa che un giorno diremo davvero finalmente addio a IE6.

Che lo abbia fatto in maniera intenzionale o meno, Microsoft ha fornito a tutti uno strumento di straordinaria utilità per implementare il progressive enhancement al momento del rilascio di IE5: i commenti condizionali. Questo piccolo pezzo di logica (che sugli altri browser si trasforma in semplici commenti HTML) ci consente non solo di indirizzare certi pezzi di markup e stili a IE, ma anche a specifiche versioni di quel browser.

Come sviluppatori attenti agli standard, dovremmo sempre iniziare a testare i nostri progetti di design nei browser più aderenti agli standard e poi fornire delle correzioni per quei browser che hanno bisogno di qualche ritocco per essere messi sulla pista giusta.

Ognuno ha il suo flusso di lavoro. Io trovo che sia ottimo il metodo di iniziare un progetto con un set standard di fogli di stile. Il mio set di base è questo:

• type.css
• layout.css
• screen.css
• print.css
• color.css

Poi, a seconda dei requisiti del progetto, aggiungo dei fogli di stile specifici per certi browser che contengono le correzioni. Nella maggior parte dei miei progetti, ad esempio, ci sono i file ie7.css e ie6.css. Se poi il progetto richiede il supporto per versioni meno recenti della 6, aggiungo i file corrispondenti (per esempio ie5.5.css, etc). Partendo da questi file inizio ad aggiungere le mie regole al foglio di stile a cui meglio si applicano del mio set di partenza.

Inizio sempre a testare su Firefox perché scrivo la maggior parte dei miei CSS usando la barra laterale Edit CSS. Appena ho finito con Firefox, inizio il test con altri browser. Nella maggior parte dei casi tutto funziona alla perfezione perché è alto il supporto degli standard. Poi arriva su IE7. Nella maggior parte dei casi non riscontro grossi problemi, ma talvolta ho la necessità di invocare hasLayout o aggiustare piccole imperfezioni nel layout. Invece di aggiungere queste piccole correzioni nei fogli di stile del mio set, le aggiungo al file ie7.css e poi collego quel file nel mio documento con i commenti condizionali:

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

Questo commento condizionale indirizza quel particolare foglio di stile a tutte le versioni di IE inferiori o uguali (lte) alla 7. Così, se qualcuno arriva su quella pagina con IE7, potrà contare sugli aggiustamenti che ho applicato all'interno del CSS. Ma se arrivano con una versione del browser che ha corretto certi bug, come ha fatto IE8 con hasLayout, il foglio di stile sarà ignorato. Se poi qualcuno arriva sulla pagina navigando con IE6, otterrà le stesse correzioni, il che è perfetto dal momento che probabilmente gli stessi errori di rendering presenti su IE7 lo sono pure su IE6. Una di queste correzioni dovrebbe consistere nell'aggiustare l'incapacità di IE (nelle versioni 7 e inferiori) di comprendere un @import con media type aggiungendo un @import per screen.css all'inizio di ie7.css senza dichiarare il media type, dunque importando gli stili che mancavano la prima volta.

Una volta che ho aggiunto le correzioni per IE7, apro IE6 e verifico che non ci sia bisogno di qualche correzione. Se così è, aggiungo un altro commento condizionale al documento collegando ad esso ie6.css:

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

Poi, semplicemente, aggiungo le regole necessarie e richieste da IE6 a quel foglio di stile ed esse saranno ignorate da IE7, mentre saranno applicate su IE5.5, etc.

Usando i commenti condizionali in questo modo, abbiamo la possibilità di gestire nel migliore dei modi i singoli browser a cui intendiamo indirizzarci per il nostro progetto mantenendo i fogli di stili privi di hack.

Altre considerazioni

Il progressive enhancement con i CSS non si limita al modo in cui si associano gli stili alla pagina: possiamo anche applicare il concetto al modo in cui scriviamo il nostro CSS.

Considerate il contenuto generato per esempio. Non tutti i browser sono in grado di gestirlo, ma è un modo eccellente per aggiungere piccoli elementi di design o di testo che non sono necessari all'usabilità della pagina ma forniscono dei miglioramenti a livello visuale o di altro tipo.

Per esempio, prendete questo modulo di contatto:

Figura 3 - Il modulo HTML usato in questo esempio (il codice è riportato qui sotto)

Quando si definisce il markup per un form di questo tipo si sarebbe tentati di inserire i due punti (:) all'interno dell'elemento label. Perché? Aggiungono qualcosa alle label stesse? No. Servono ad uno scopo, a fornire un'ulteriore traccia visuale all'utente, sono superflui per la label e dovrebbero essere lasciati fuori dal markup HTML (le interruzioni di riga sono marcate con »):

<form id="contact-form" action="#" method="post">
  <fieldset>
    <legend>Contact Us</legend>
    <p>Send us a message. All fields are required.</p>
    <ol>
      <li>
        <label for="contact-name">Name</label>
        <input type="text" id="contact-name" name="name" />
      </li>
      <li>
        <label for="contact-email">Email</label>
        <input type="text" id="contact-email" name="email" />
      </li>
      <li>
        <label for="contact-message">Message</label>
        <textarea id="contact-message" name="message" rows="4" »
        cols="30"></textarea>
      </li>
    </ol>
    <button type="submit">Send It</button>
  </fieldset>
</form>

Il contenuto generato è perfetto in queste situazioni per aggiungerli nuovamente al documento:

label:after {
  content: ":";
}

Approcciare il form in questo modo ci dà la massima flessibilità per rimuovere tutte le decorazioni di quel tipo dal nostro sito semplicemente editando il CSS piuttosto che dovendo mettere mano ad ogni singolo form. Questa tecnica degrada anche bene perché il form non viene reso inutile e inusabile senza i due punti: un esempio perfetto di progressive enhancement.

Potrete anche trovare che scrivere regole con selettori più avanzati può aiutarvi ad implementare nel modo più efficace il progressive enhancement al vostro sito indirizzando certi stili ai browser più avanzati. Un grande esempio è il selettore di attributo, che non è non intepretato da IE6 e altri browser dei quella generazione. Egor Koss ha giocato un po' con il concetto nel suo progetto destinato a CSS Zen Garden intitolato Gemination.

Figura 4 - Un confronto del design Gemination di Egor Koss visto su un browser con buon supporto degli standard e su IE6

Come ha fatto? Bene, questa è una versione leggermente modificata del suo codice:

/* <= IE 6 */
body {
  margin: 0;
  text-align: center;
  background: #600 none;
}
/* IE 7, Mozilla, Safari, Opera */
body[id=css-zen-garden] {
  margin: 100px 0 0;
  padding: 0;
  text-align: center;
  background: transparent url(squidback.gif);
}

Le differenze sono notevolissime e illustrano alla perfezione come il progressive enhancement possa essere applicato nei CSS.

In modo simile, Andy Clarke si è divertito un po' con IE6 sul suo sito. Smanettando con i filtri disponibili per IE e usando alcuni commenti condizionali, è stato in grado di eliminare tutti i colori dal suo sito e a fornire del corredo grafico alternativo per ottenere un'esperienza davvero 'a bassa fedeltà'.

Figura 5 - Un confronto del sito web di Andy Clarke visto su un browser con buon supporto degli standard e su IE6

La tecnica con cui si rende tutto in scala di grigi è implementata aggiungendo il seguente blocco di codice in un foglio di stile indirizzato a IE6 usando un commento condizionale:

/* =img for Internet Explorer < 6 */
img {
  filter: gray;
}

Sebbene questi due esempi possano includere molti più trucchetti di quelli che potrete mettere in pratica nel vostro lavoro quotidiano, certamente rappresentano delle eccellenti testimonianze dei modi in cui potete praticamente adottare il progressive enhancement con i CSS.

Mettere tutto insieme

Come abbiamo visto, ci sono molti modi per iniziare ad implementare il progressive enhancement sul vostro sito usando i CSS. Quello più semplice, e forse il migliore, consiste nell'organizzare i vostri fogli di stile e nel prendere decisioni consapevoli sul come collegare questi fogli di stile al vostro documento. Gestire le idiosincrasie di IE è facilissimo una volta che avrete compreso il potere dei commenti condizionali e potrete ottenere un maggiore livello di granularità giocando un po' nel CSS stesso attraverso un uso accorto di certi selettori e una valutazione attenta delle siuazioni in cui li userete.

Ora ciascuno di voi è un po' più esperto di progressive enhancement. Unitevi allora a me per il terzo appuntamento della serie, quello dedicato al progressive enhancement con Javascript.