21 Ott 2016

Gmail supporta le email responsive, finalmente.

È sicuramente la grande novità dell'autunno 2016, un vero terremoto, questa volta in senso positivo, per l'email marketing: come annunciato qualche settimana prima, dal 30 settembre Gmail ha cominciato a supportare i CSS non inline, comprese le famigerate media query, il vero motore della responsività web.

Nel corso di questi anni, con la crescita esponenziale dell'uso degli smartphone, inviare newsletter responsive è diventato irrinunciabile, ma nel contempo farlo si è dimostrato un vero e proprio bagno di sangue: molti client di posta e sistemi webmail avevano - e in parte hanno tutt'ora - notevoli incompatibilità con l'uso moderno dei CSS.

Da qui il susseguirsi di trucchi e tecniche, inlining, hybrid coding e Fab 4, soprattutto per contenere il problema verso Gmail e Outlook.

Gmail Responsive

Gmail fino a qualche settimana fa - e in parte anche ora - non supportava nella maniera più assoluta CSS embedded e classi, eliminandoli dall'email stessa, rendendo dunque impossibile applicare gran parte degli effetti CSS, soprattutto quelli legati alle media query, indispensabili per un vero comportamento responsive.
È dunque logico che l'annuncio di Google a metà settembre abbia scatenato un certo entusiasmo fra gli addetti ai lavori: il traffico verso caselle Gmail è sicuramente importantissimo e coinvolge non solo caselle personali ma anche un gran numero di domini aziendali, ospitato su G-Suite (ex Google Apps).

Soprattutto per il mercato statunitense quest'adozione potrebbe significare una vera rivoluzione nell'email design; il condizionale è comunque d'obbligo al momento, per una serie di motivi.

Come funzionava Gmail

Il "vecchio" Gmail operava sull'email in ingresso una serie di trasformazioni importanti: gli stili non inline venivano completamente eliminati, le classi, ormai inutili, visto lo stripping dei css, rinominate e anche gli stili inline subivano una serie di modifiche, in particolare le direttive display, alcune proprietà del background e anche posizionamenti assoluti e margini.
Questa serie di aggiustamenti era in gran parte giustificata dal fatto che la webmail Gmail include l'email direttamente nel DOM dell'interfaccia: posizionamenti assoluti, e altre direttive potevano andare ad interferire con l'interfaccia stessa, creando anche pericoli per la sicurezza del sistema.

Meno comprensibile è come queste limitazioni siano state mantenute per anni anche nelle app Android e IOS, se non per il fatto che di fatto che le trasformazioni vengono fatte a monte, prima di servire l'email all'applicazione o alla webmail.

A causa di queste pesanti limitazioni non era possibile fare affidamento a metodi moderni per generare una versione mobile dell'email. Per altro le applicazioni stesse tentavano di ovviare, facendo modifiche non chiare alla larghezza delle tabelle (applicando delle classi munged-table), rendendo ancora più complicato il tutto.

Due tecniche sono sorte per ovviare a questi problemi: la prima, la più utilizzata ancora oggi, è il cosidetto hybrid coding, che funziona lavorando sulla terna width, min-width e max-width, riuscendo a regalare anche a Gmail una versione responsive, seppure non perfetta.
La seconda, nata di recente, è il cosidetto metodo Fab4, che abbandona completamente il layout basato su tabelle, per utilizzare unicamente div, aggiungendo alla terna min-width, max-width, width, la funzione CALC di CSS.

Grazie a questo espediente FAB4 è (era) in grado di regalare anche ai possessori di casella Gmail una perfetta versione responsive, al prezzo di un codice non immediatamente comprensibile ed una certa instabilità con client e webmail problematici.

Insomma, era sicuramente - e per tanti versi è ancora - un mondo difficile.

E adesso?

Gmail ha annunciato e cominciato a rilasciare il supporto agli stili embedded e alle media query, rendendo tutto quanto estremamente più semplice, più o meno.
Quando il processo di adozione di questi cambiamenti sarà completo, non ci sarà più necessità di trucchi e tecniche particolari per creare email responsive compatibili con Gmail. Al momento però la transizione non è ancora completa: pare che l'applicazione IOS non abbia ancora recepito le modifiche e anche l'adozione delle stesse per gli account Google Apps/G-suite è a macchia di leopardo.

Questo significa che al momento inviando una email a indirizzi gmail - o aziendali ospitati da gmail - non si è certi di che tipo di rendering verrà adottato.

Oltre a questo è bene segnalare alcuni limiti: gli stili eccedenti gli 8.192 caratteri vengono eliminati completamente, questo anche se gli stili vengono divisi in più tag <style>, per cui bisogna porre attenzione e non eccedere nel creare stili articolati e complessi.
È necessario anche tenere presente che tutte le vostre classi verranno rinominate e prefissate, in maniera da evitare problemi con la skin e gli stili dell'interfaccia della webmail.

Altra stranezza, o meglio funzionamento non ottimale, è il comportamento delle media-query su webmail desktop.
Come detto in precedenza Gmail non utilizza Iframe per includere l'email in lettura, per cui i riferimenti delle media-query rimangono quelli della viewport - o del display, al limite - senza tener conto dello spazio occupato dall'interfaccia stessa della webmail.
Ciò implica il fatto che se tengo una finestra piuttosto stretta, un template basato unicamente su media-query non farà scattare la versione mobile, anche se servirebbe, mentre un design hybrid visualizzerà comunque la versione corretta.

È ora di abbandonare gli stili inline?

No, al momento no.

Gmail non ha completato la transizione e in ogni caso anche altri webmail e client non supportano ancora gli stili embedded (rimanendo in Italia Libero e Tiscali, che insieme registrano più traffico di Gmail nel nostro paese). Sicuramente questa transizione aiuterà l'email design e in prospettiva altri potrebbero seguire la strada di Gmail, andando finalmente a semplificare il lavoro dell'email designer.

È un punto di partenza, già si parla di supporto esteso della tipografia e di altre mirabilie; per ora esultiamo, ma in maniera piuttosto composta.

Aggiungi un commento

Filtered HTML

  • Indirizzi web o e-mail vengono trasformati in link automaticamente
  • Elementi HTML permessi: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Linee e paragrafi vanno a capo automaticamente.

Plain text

  • Nessun tag HTML consentito.
  • Indirizzi web o e-mail vengono trasformati in link automaticamente
  • Linee e paragrafi vanno a capo automaticamente.