EmailOnAcid a fait plein de tests pour comprendre comment le poids d’un e-mail affecte sa délivrabilité. En résumé : il est préférable de conserver le poids de son HTML sous la barre des 100 Ko, et le poids des images n’a pas d’importance.
Outlook.com supporte bien les propriétés CSS Float et Margin
En janvier 2013, le monde entier découvrait avec effroi que le webmail Outlook.com (dans sa version desktop et mobile) supprimait systématiquement les propriétés CSS float et margin (et ses dérivées margin-top, margin-left, etc.). C’est fortement dommage, parce que des flottants et des marges, ça peut éventuellement servir en intégration (doux euphémisme).
Mais tout récemment, un tweet de Mark Robbins m’a mis la puce à l’oreille sur une faille insoupçonnée de ce filtrage d’Outlook.com. En fait, Outlook.com supprime simplement toute les propriétés float et margin. Mais pas Float et Margin. Ni floaT et margiN. Ni FlOaT et MaRgIn. Ou FLOAT et MARGIN. Vous avez compris l’idée : simplement en changeant la casse de la propriété, on arrive à passer au travers du filtrage d’Outlook.com. La syntaxe des propriétés CSS n’étant pas sensible à la casse, cela ne pose pas de problème de compatibilité ailleurs.
Video in email
StyleCampaign fait le tour des solutions pour intégrer de la vidéo dans un e-mail (ou au moins faire semblant). Il n’y a pas de recette miracle, et le support des vidéos HTML5 dans les e-mails est encore anecdotique. Mais n’empêche que même avec un GIF (de 1,7 Mo, certes), certains font de chouettes e-mails.
Gmail supporte bien la balise <style> et les media queries
Une croyance courante dans l’intégration d’e-mails est de dire que Gmail ne supporte pas les styles ou le responsive design. En réalité, c’est un peu plus fin que ça. En avril dernier, EmailOnAcid rappelait que Gmail supporte bien la balise <style>.
Intrigué, j’ai fait mes petits tests, et je confirme : la version desktop du webmail Gmail conserve bien une balise <style> incluse dans le <head> d’un e-mail. Toutes les règles sont bien conservées, mais préfixées par une classe propre à Gmail. Ainsi le code suivant…
.toto { background:red; }
@media only screen and (max-width:600px) {
.toto { background:white; }
}… sera transformé en :
div.m1479b618d2293d85 .toto { background:red; }
@media only screen and (max-width:600px) {
div.m1479b618d2293d85 .toto { background:white; }
}Le hic (parce que forcément il y a un hic), c’est que Gmail supprime toutes les classes et identifiants au sein du code HTML de l’e-mail. Du coup, même si ces styles sont bien conservés, aucun n’est appliqué puisque plus aucune classe ou identifiant ne sont présents.
Mais du coup, ça signifie qu’on peut jouer sur des styles ciblant des balises. Par exemple, le code suivant transformé par Gmail sera bien appliqué dans votre e-mail :
div.m1479b618d2293d85 table td { background:red; }On pourrait alors imaginer styler des éléments non plus par classe mais par leur position dans le code HTML. Malheureusement, Gmail supprime toute règle CSS contenant des pseudo-sélecteurs comme :first-child ou :nth-child().
Par contre, Gmail conserve bien les règles utilisant des sélecteurs d’éléments enfants ou adjacents, comme >, + ou ~. On peut alors jouer sur des combinaisons de balise pour cibler un élément en particulier. Par exemple, pour cibler le troisième tableau d’un e-mail, on pourrait créer la déclaration suivante :
table + table + table { background:red; }Toutefois, cette règle s’appliquera aussi pour tout autre tableau précédé de deux tableaux (donc aussi le quatrième, le cinquième, etc.).
Mais surtout, ces bidouilles ne concernent que la version desktop du webmail Gmail. La version mobile de Gmail, ainsi que les applications iOS ou Android, continuent de supprimer toute balise <style>.
Office 365 et ses nombreux caprices pour les designers d’e-mails
James White fait le tour des points vraiment pénibles de Office 365 (Outlook Web Access) pour l’intégration d’e-mails. Sa phrase d’introduction résume bien le sujet :
Après avoir creusé le sujet, j’en arrive à la conclusion que l’application Office 365 OWA est pire que Outlook 2007 ou 2013 en terme de support des standards.
Créer un design responsive centré sans media queries
Campaign Monitor explique comment créer un e-mail responsive propre, sans media queries, en se basant sur la propriété CSS display:inline-block plutôt que sur des tableaux.
How to Build Kickass Emails
Kevin Mandeville, de chez Litmus, a mis en ligne les slides de sa conférence « How to Build Kickass Emails ». C’est monstrueux (dans le bon sens du terme), et c’est très très complet. C’est même un peu drôle. Et sa page dédiée diffusée juste après la conférence est elle aussi (en plus d’être une excellente idée) bourrée de liens utiles.
What you can learn from Basecamp’s redesigned email newsletter
Campaign Monitor revient sur le nouveau design des e-mails de Basecamp. Comme souvent chez Basecamp, c’est simple et efficace. J’aime particulièrement l’objet de l’e-mail qui a généré le plus d’ouvertures.
CSS triangles
En février dernier, Mark de chez Email Code Geek expliquait comment créer des triangles en CSS pour des e-mails. C’est pas si différent que pour le web, à l’exception du code spécifique à Outlook.
The Ultimate Guide to Email Image Blocking
Litmus publie « le guide ultime sur le blocage des images », avec de sages conseils pour optimiser le rendu d’un e-mail avec images bloquées.