Il sito del progetto Email standards project, ufficialmente lanciato oggi, è dedicato a chi si interessa, per lavoro o per diletto, alla resa del codice HTML nei vari client email presenti sul mercato.
Il progetto va a colmare un vuoto enorme nel panorama del web: se da anni, infatti, è attivo e vitale il movimento per la diffusione e l’adozione degli standard web nei browser e per lo sviluppo dei siti web, per quanto riguarda le email in formato HTML siamo ancora molto indietro.
La motivazione della nascita del progetto, che vede in prima fila Freshview, Mark Wyner e Luke Stevens, è ben riassunta sul sito:
The project was formed out of frustration with the inconsistent rendering of HTML emails in major email clients.
Chiunque abbia mai ricevuto un’email in formato HTML può rendersene conto: il programma di posta che abbiamo deciso di utilizzare (Outlook o Outlook Express, Thunderbird, la webmail di Gmail o Yahoo! ecc.) tenderà a costituire un ostacolo tra il layout preparato da chi ha inviato l’email e quello che di fatto vediamo sul nostro schermo.
Non si tratta di un problema di poco conto, se è vero che l’email è considerata da sempre una killer application e se è vero che tutti noi siamo abbonati a una o più newsletter, per essere sempre informati sulle ultime novità relative ai prodotti e alle aziende più interessanti. L’appuntamento periodico (settimanale, mensile o talvolta quotidiano) con la newsletter dell’agenzia di viaggi, piuttosto che le ultime offerte del nostro sito preferito del settore automobilistico, è un classico di qualsiasi utente di Internet.
Mentre nel mondo dei browser sono stati compiuti passi da gigante e ormai un sito progettato correttamente viene reso in maniera pressoché identica su tutti i browser moderni (Internet Explorer, Firefox, Opera ecc.), il problema di chi si occupa di gestire e inviare le newsletter via email è ad oggi ancora irrisolto: ogni client di posta elettronica fa storia a sé e, se non si sta particolarmente attenti nella preparazione del codice HTML, quasi certamente qualcuno scriverà lamentandosi di aver ricevuto l’email in formato illeggibile.
Di chi è l’errore? Verrebbe subito da incolpare lo sviluppatore dell’HTML: di fatto è lui (o lei) che dovrebbe sapere, in virtù delle sue competenze, quali proprietà dei CSS è meglio non utilizzare e quali sono quelle più comunemente supportate. Talvolta, però, l’esigenza di adeguarsi alle direttive aziendali, che impongono l’uso di particolari font, colori, dimensioni ed elementi grafici (sfondi, icone, immagini ecc.), porta a dover appesantire il codice HTML per renderlo compatibile con il maggior numero di piattaforme… ed evitare quindi l’email di chi giustamente si lamenta di ricevere una newsletter illeggibile.
Il risultato è quindi, nella maggior parte dei casi, un codice HTML appesantito, con tabelle annidate per essere sicuri che l’email apparirà esattamente come voluto.
In realtà, però, il problema non è imputabile solo allo sviluppatore del codice – e non lo dico solo per difendermi 😉
Buona parte del torto sta infatti nei programmatori che hanno sviluppato il client di posta elettronica, senza dare troppa importanza alla resa visiva del codice HTML, in conformità alle direttive del consorzio W3C.
Due esempi su tutti. Una piattaforma diffusissima in ambito aziendale è Microsoft Outlook: l’ultima versione (Outlook 2007) risulta addirittura meno performante – in termini di supporto di HTML e CSS – della versione precedente; una sorta di involuzione, insomma. Oppure si pensi a Gmail, la diffusissima webmail di Google: il supporto dei fogli di stile è minimo e di default le immagini nelle email sono disabilitate (sta all’utente la scelta, introdotta per motivi di sicurezza, di visualizzare le immagini).
In questo scenario, alla fine del 2007, nasce quindi l’Email Standards Project, sulla scorta di quanto realizzato in questi anni dal Web Standards Project, con il quale condivide tra l’altro le due grandi aree in cui operare: da una parte, l’educazione e la diffusione degli standard web (HTML e CSS) presso gli sviluppatori e i designer; dall’altra, lavorare fianco a fianco con chi progetta e sviluppa client di posta elettronica, così che in futuro il supporto degli standard sia più consistente e diffuso.
Per quanto mi riguarda – da navigatore iscritto a diverse newsletter, ma anche come sviluppatore di newsletter per conto di aziende – l’arrivo di questa nuova iniziativa avrà sicuramente tutto il mio interesse e spero che anche questo post possa contribuire alla diffusione della notizia.
Nell’attesa di seguire gli sviluppi dell’Email Standards Project, ho già aggiunto il blog dedicato al mio feed reader.
A tutti gli sviluppatori di HTML che, come me, vogliono assicurarsi che la newsletter venga visualizzata correttamente da migliaia di persone, consiglio di leggere con un po’ di calma i report relativi ai client di posta più diffusi.
Technorati Tags: web standards, email standards project, email, standard web, html, blog
Io leggo le email sempre in formato testo semplice proprio per evitare l’HTML.
Ci sono troppi problemi di sicurezza. Abilitare il rendering HTML nel client di posta è veramente poco saggio soprattutto per chi usa Windows.
Hai ragione e ti confesso che anch’io non impazzisco, da utente, per le email in formato HTML e, se possibile, preferisco ricevere le email in formato txt.
Diverso è il discorso dal punto di vista delle aziende: se “n” persone si sono iscritte alla newsletter e hanno spuntato la casella “formato HTML”… beh, c’è poco da fare: da “html-ista” mi tocca farlo e basta. 🙂
Ad oggi, l’unica cosa che posso fare è cercare di far capire bene alle aziende che certe scelte comporteranno problemi di rendering in qualche client.
Ma le policy aziendali (penso soprattutto alle aziende di grandi dimensioni), spesso sono piuttosto rigide: la tal newsletter deve avere il font rosso, su sfondo grigio, 2 colonne ecc. ecc.
Ecco perché spero tanto che in futuro la resa dell’HTML e dei CSS nei client possa uniformarsi: abbiamo vinto “la guerra dei browser”, ora spero sia giunta l’ora dei client email… 😉