Sostanzialmente quando si parla di CSS applicati alle e-mail esiste ancora parecchia confusione sia sui modi di applicare gli stili sia sul supporto allo standard CSS da parte dei client di posta. Scopo di questo articolo è quello di cercare di fare chiarezza basandomi sulla mia personale esperienza.
Il problema dei client
Per il W3C, un client di posta è uno user-agent che interpreta i CSS. Ma quale versione dei CSS? Come minimo comun denominatore possiamo considerare i CSS 2, anche se questo riferimento non può essere universale dato l'enorme numero di client disponibili.
È proprio il numero che gioca a nostro sfavore: se per i browser possiamo testare i nostri contenuti su tre o quattro user-agent installati sul nostro computer, lo stesso non si può dire per i client di posta.
Io ho usato nel corso del tempo Outlook, Thunderbird, Evolution e Mail, quindi la mia esperienza si limita certo ai client più diffusi, ma non a tutti! Se a questo aggiungiamo il fatto che gli utenti possono scegliere di utilizzare la web mail per controllare la posta, il discorso si complica ulteriormente.
Qual'è poi la frequenza con cui un utente installa un nuovo client di posta perchè magari ha dei problemi con quello predefinito? Su Mac c'è una vastissima gamma di possibilità, così come per gli altri sistemi operativi.
Nuovo client, nuovo user-agent, nuovo rendering CSS: l'e-mail HTML da noi formattata verrà visualizzata in modo diverso. E dato che il W3C non ha ancora fornito un modo per individuare lo user-agent tramite CSS (i commenti condizionali sono stati abbandonati dalla stessa Microsoft a partire da IE10), magari con una media query, noi non possiamo sapere quale programma gestirà i nostri stili.
La regola in questi casi è quella di scrivere codice il più possibile aderente agli standard al fine di livellare le possibili differenze. Come? Gli user-agent che supportano meglio i CSS visualizzeranno l'e-mail al meglio, mentre gli altri offriranno una versione leggermente degradata (non disintegrata!) ma comunque fruibile. E gli altri? Una struttura linearizzata.
Ecco perchè il codice HTML delle e-mail dovrebbe essere il più strutturato possibile. Le tabelle, usate da molti generatori di e-mail HTML, possono essere una soluzione da extrema ratio, ma tenete presente che i lettori di schermo, usati dalle persone cieche, potrebbero avere dei problemi con questo tipo di strutture.
Alcuni punti da considerare:
- Immagini di sfondo – Alcuni client non le supportano.
- Viewport e elemento body – Molti client non permettono di ridurre lo spazio di visualizzazione o comunque modificare la larghezza dell'elemento
body. - Posizionamento e floating: Alcuni client possono presentare ancora dei problemi.
Le specifiche CSS non contemplano tutti i possibili scenari d'uso dei CSS. Si parla di palmari, tablet, proiettori, televisori, computer, cellulari, stampanti, dispositivi braille, addirittura terminali. Mancano all'appello i client di posta.
Sono browser dalle capacità limitate? Devono essere equiparati agli altri dispositivi? Se pensiamo che il formato HTML è opzionale per questo tipo di programmi, capiamo anche come anche i CSS, di fatto, sono opzionali.
Stili inline o esterni?
Se fossimo liberi di scegliere, tutti noi sceglieremmo di usare CSS esterni, perchè in fondo questa è la soluzione più logica e pratica e, soprattutto, è quella a cui siamo più abituati.
Purtroppo non siamo noi a scegliere, ma i contesti in cui operiamo. Giusto ieri mi è arrivata la richiesta di usare stili inline per una newsletter, perchè c'erano dei problemi con la distribuzione delle e-mail.
E sia.