Faut-il arrêter d’écrire ses styles en ligne dans des e‑mails ?

Jusqu’à l’an dernier, Gmail était l’un des plus gros clients mail ne supportant (presque) que des styles en ligne. Les webmails de Yahoo, AOL, Outlook.com et, oui, même les versions d’Outlook (de 2007 à 2016 sur Windows) utilisant le moteur de Word supportent les balises <style> depuis longtemps. La mise à jour de Gmail en 2016 a tout changé en ajoutant enfin officiellement le support de balises <style> et d’attributs class et id. Alors en 2017, faut-il arrêter d’écrire ses styles en ligne dans des e‑mails ?

La question est réapparue le mois dernier quand Kevin Mandeville de Litmus a partagé son retour expliquant pourquoi Litmus n’a pas utilisé de styles en ligne dans sa première newsletter de l’année. Si ça a beaucoup de sens pour Litmus et leur audience, et s’ils ont fait un bon travail pour s’assurer d’un bon rendu dégradé, je ne suis pas sûr qu’il soit encore temps de recommander à tout le monde d’arrêter d’utiliser des styles en ligne.

Voici quelques points à prendre en compte, avec des pours et des contres.

Tous les clients mail ne supportent pas la balise <style>.

Nombre de clients mail internationaux ne supportent pas la balise <style>. Des clients populaires comme Libero (en Italie), Mail.ru ou Yandex (en Russie), Nate ou Naver (en Corée), T‑online (en Allemagne), Telstra (en Australie) ou Terra (au Brésil).

Parfois ça arrive même seulement sur certaines versions de certains clients mail. En France, l’application iOS de SFR ou l’application Android d’Orange ne supportent pas non plus la balise <style> (alors que leurs contreparties desktop ou mobile, oui).

Mais surtout, même Gmail, Yahoo ou Outlook.com ne supportent parfois pas la balise <style>. C’est vrai pour Gmail sur Android avec un compte autre que Gmail (surnommé par la communauté « GANGA »). C’est vrai aussi pour Yahoo dans leur application Android ou leur webmail mobile. Et c’est vrai également pour Outlook.com sur mobile dans l’ancienne version de leur webmail (toujours disponible pour certains utilisateurs en Europe).

Les clients mail ont leur propres styles par défaut.

C’est particulièrement problématique dans les webmails, où le HTML de votre e‑mail héritera des styles trop génériques des webmails. Par exemple, le webmail desktop de Gmail a la règle CSS suivante dans son interface pour changer la couleur par défaut des liens.

.ii a[href] {
	color: #15c;
}

Comme c’est une règle assez générique, elle s’applique aussi pour les liens à l’intérieur de vos e‑mails. Et comme le sélecteur utilisé est assez spécifique (ciblant une classe, une balise et un attribut), vous ne pouvez pas simplement le surcharger avec une règle générique telle que a { color: inherit; }. Et comme Gmail ne supporte pas les sélecteurs d’attributs, vous ne pouvez pas utiliser un sélecteur a[href]. Pour autant, on peut résoudre tout ça en utilisant un sélecteur plus spécifique. Mais il faudra répéter l’opération pour chaque client mail.

L’un des avantages insoupçonnés d’écrire ses styles en ligne est que ça surcharge automatiquement les styles par défaut des clients mail, sans que vous n’ayez à passer des heures à enquêter dans chacun d’eux.

Ça rend votre code plus léger.

C’est à mon avis le plus gros argument en faveur de l’arrêt de l’écriture des styles en ligne. J’ai fait une comparaison rapide sur la newsletter de Litmus. Envoyé sans styles en ligne, l’e‑mail pèse environ 58 Ko. Avec des styles en ligne (automatiquement générés avec Putsmail), l’e‑mail aurait pesé autour de 73 Ko. C’est une énorme différence d’environ 25 % !

Un code HTML plus léger signifie qu’il sera plus rapide à charger. Mais surtout, ça peut aider à éviter de retrouver son e‑mail tronqué par certain clients mail. Par exemple, le webmail desktop de Gmail tronque n’importe quel contenu après les 102 premier kilo-octets d’un e‑mail. Votre destinataire devra cliquer sur un lien « Afficher le message en entier » pour afficher l’e‑mail correctement.

Par contre, ne pas écrire les styles en ligne peut devenir contre-productif pour des éléments qui n’apparaissent qu’une seule fois dans un e‑mail. Un attribut class plus une balise <style> pèsera plus lourd qu’un simple attribut style en ligne.

Écrire des styles en ligne, c’est une véritable plaie.

Vraiment ? C’est sûr que si vous venez du monde du développement Web, c’est l’une des premières bizarreries du monde de l’intégration d’e‑mails qui vous sautera aux yeux. Mais dans ce monde, justement, on écrit les styles en ligne depuis le début. Utiliser vos propres snippets, des outils comme Emmet ou l’un des nombreux inliners existant rend cette tache vraiment indolore.

Il y a probablement d’autres arguments pour ou contre l’écriture des styles en ligne dans les e‑mails. Mais j’aimerais conclure cet article avec quelque chose que j’avais écrit il y a cinq ans sur mon autre blog.

Le mantra de l’intégrateur (d’e‑mails)

Quand je code, que ce soit pour le Web ou pour un e‑mail, j’en reviens toujours à me poser la question suivante…

Qu’est-ce qui est le mieux pour l’utilisateur ? 

Je dois intégrer un carousel pour une page web. Je peux me mettre à la recherche d’un script déjà existant répondant parfaitement à mes besoins. Ou je peux en coder un moi même. Qu’est-ce qui est le mieux pour l’utilisateur ?

La maquette d’un e‑mail utilise des polices tierces. Je peux coder cet e‑mail tout en images. Ou je peux intégrer cette police en CSS et laisser le texte en HTML, en sachant cependant que ça ne fonctionnera pas partout. Qu’est-ce qui est le mieux pour l’utilisateur ?

Tous les clients mail ne supportent pas la balise <style>. Je peux écrire tous mes styles en ligne. Ou je peux m’assurer que l’e‑mail se dégradera gracieusement et s’affichera aussi bien que possible sur les autres clients mail. Qu’est-ce qui est le mieux pour l’utilisateur ?

Toute la beauté de cette question réside dans le fait qu’elle n’a pas de réponse absolue. Ce qui fonctionne pour un projet ne fonctionnera peut-être pas pour un autre. Ce qui est vrai aujourd’hui ne le sera peut-être plus demain.

Donc si je ne suis pas emballé par l’idée d’arrêter d’écrire des styles en ligne pour la plupart des e‑mails sur lesquels je travaille, je suis heureux de savoir que c’est désormais quelque chose qu’on peut sérieusement envisager.

English version: Should we stop inlining styles in emails?