Cassures sous les images sur Outlook.com / Office365 ?

Salut les p’tits clous ! Je reviens pour vous parler d’un point technique : les cassures sur Outlook ! Et ouiiii, je n’ai pas publié d’article depuis quelques temps, mais cela ne m’a pas empêché de penser à vous, vous savez ! Et aujourd’hui, je vais vous raconter une histoire… L’histoire du grand méchant Microsoft… Rien que ça, déjà, ça fait froid dans le dos…

dr evil

J’ai dernièrement rencontré une « petite » difficulté qui revient à répétition depuis sur mes tests EmailonAcid. Ce problème de rendu ne s’était jamais manifesté jusque-là, mais a émergé, de mémoire, la semaine passée (aux alentours du 20 mars 2017… Il devait être 15h11…). Lors de mes tests d’email preview, j’ai observé de légères lignes blanches sur Outlook.com et Office 365 apparaissant sous mes images. Bien sûr, et vous vous en doutez, j’avais déjà correctement renseigné mes « display:inline-block » à chacune de mes images. Mais rien n’y faisait. Je précise que ces cassures apparaissaient alors uniquement sur mes tests EmailonAcid, mais pas sur mes tests réels. Je le signale car cela aura une importance dans la suite de cet article. (Teasing !!!! J’suis bon pour le suspens, j’suis sûr que j’aurai au moins pu écrire un S.A.S. Je l’aurai appelé « Vengeance Outlook » ou un truc comme ça…)

screenshot

Hop, le petit screenshot d’exemple pour bien se rendre compte! J’ai même mis des couleurs de fond qui piquent à mes cellules pour qu’on voit bien les cassures!

Comme je vous le disais donc, il était 15h11, l’heure de la digestion mesquine quoi, où mes yeux luttent parfois malgrè l’écoute du dernier album, pourtant énergique, d’Olafur Arnalds pour me tenir éveillé… Après avoir tenté de multiples « Reprocess » sur EmailonAcid pensant que l’erreur venait du screenshot de la plateforme (la solution de facilité, toi-même tu sais!), je décide de tester mon code sur l’email preview instantané de Litmus. Même constat. Qu’ai-je bien pu faire, au sein de mon code HTML, pour que cela se produise ? Je procède toujours de la même façon pourtant, et je change rarement mes habitudes (un peu comme Ted Bundy quoi). Je teste alors de petits fix, et m’aperçois qu’un « style=«font-size:0px ;» » règle le problème. Coooool ! mais au fait… pourquoi ?

christopher lloyd

Je prends le taureau par les cornes et décide de poser la question à la Communauté Litmus.

Une communauté d’#emailgeek aussi passionnés que nous le sommes, prêts à tout pour trouver des solutions, tester, discuter, aider… Bref, une communauté comme on les aime… Je vous laisse apprécier ici mon ton pédagogique et mon anglais parfait de chez Google translate. Oui, ok, j’ai publié ça sous le compte de Grégory, alors vous allez penser que je n’assume pas mes questions, mais non! Pas du tout! De toute façon, m’en fiche, j’ai l’immunité! 😛

Ô surprise, je découvre dès le lendemain que ma question n’est pas restée sans réponse. Elle a même suscité un certain engouement (et la création d’articles comme chez EmailMonks). Et c’est carrément MONSIEUR Kevin Mandeville qui me répond en premier. Selon Kevin, une mise à jour a été faite chez Outlook.com et Office 365, afin de donner la possibilité, aux image non « cliquables » (autrement dit sans lien hypertexte) d’être visualisées « au sein de l’email comme des éléments indépendants » (enfin de ce que j’en comprends…). De ce fait, chaque image sans lien hypertexte est automatiquement entourée d’une balise <button>. De plus, toutes les images, même si elles ont un lien hypertexte, sont aussi entourée d’une balise <div style= »display :inline-block ; »>.

Se sachant (on dit bien se faisant), Kevin me conseillait alors de mettre un lien sur toutes mes images pour ne pas rencontrer de balises <button>, d’entourer moi-même mes images par des div avec une class spécifique, et de préciser à cette classe un comportement en « display :block ». Par exemple :

Deviendra donc sur Office 365 et Outlook.com :

(Si vous vous demandiez par la même occasion pourquoi un « x_ » est ajouté sur la class, allez mater cet article de Rémi Parmentier sur le nouvel Outlook.com)

Il ne nous resterait donc plus qu’à cibler les div ainsi :

J’ai remercié Kevin pour sa réponse très pertinente (c’est la moindre des choses) et j’ai demandé si il savait depuis quand Outlook.com et Office 365 avait fait cette mise à jour, et pourqu? Mais malheureusement, pas de réponse (en même temps Kevin ne bosse pas chez Microsoft). C’est ici que j’ai justement eu une réponse de Rémi Parmentier, précisant (et c’est ce que je vous avais signalé plus haut) qu’il ne voyait pas ce problème sur son compte Outlook.com (en France donc) et soulevait ainsi la question de :

« Peut-être que la mise à jour n’a pas été faite pour tous les utilisateurs Outlook.com? Ainsi, nous verrions le problème apparaître sur Litmus ou EmailonAcid, mais pas sur nos tests réels. »

J’ai ensuite reçu d’autres réponses, très pertinentes d’ailleurs : Il n’est pas nécessaire de mettre des liens sur toutes mes images, mais plutôt de cibler de façon générale les <div> et les <button> dans mon style en tête de mail et d’y spécifier un display :block !important ; D’autres précisent que la solution ne fonctionne pas complètement sur Safari, et qu’il faut ajouter des « margin:0 !important ; » et « padding:0 !important ; » aux div et button.

Pour ma part, le fait d’ajouter des « display:block » de façon aveugle sur toutes les <div> me paraissait un peu risqué. Lorsque l’on part sur des conceptions d’email fluides (pour un affichage responsive sur Gmail app par exemple), on utilise précisément des <div> pour certaines cellules qui doivent, en version desktop, s’afficher côte à côte. De plus, lorsque vous utilisez cette méthode de conception, vous renseignez (en principe) un « font-size :0 » à la cellule comprenant vos <div>. De ce fait, les cassures ne sont pas sensées apparaître sur les images comprises dans mes <div>…

Je pense qu’il faut donc réussir à trouver un fix qui ne vienne pas empiéter sur ce type de structure. En soit, on pourrait rester probablement sur une solution avec un « font-size:0px ; » à toutes les cellules comprenant des images, solution qui semble régler le souci… Oui mais du coup, quid du rendu sur nos textes alternatifs ? Ils deviendront illisibles !

Selon moi, la solution idéale se rapproche de celle de Kevin Mandeville. On ne peut cibler toutes les <div> sans dissociation (cela nuirait gravement à la construction d’un mail fluide pour Gmail app). La solution serait de créer un fix ne ciblant donc que les images au sein de certaines <td> concernées par une class en particulier. Et j’en reviens donc à la solution proposée par Kevin, qui me semble la meilleure :

Deviendra donc sur Office 365 et Outlook.com :

Il ne nous resterait donc plus qu’à cibler les div (et les <button>) ainsi :

Et voilà les copains ! Je pense que ce point technique méritait d’être soulevé, parce qu’il risque de faire tourner la tête à plus d’un ! (Comme conclusion, y a pas mieux…)

A propos de Thomas Defossez

Thomas a démarré sa carrière en tant qu'intégrateur emailing chez Experian avant de créer sa propre agence web. Aujourd’hui, Thomas a décidé de se focaliser sur l’email afin d’être un spécialiste de l’intégration HTML de ce médium. Depuis fin 2014, Thomas collabore à divers projets de l'Agence Badsender.com.

Check Also

Web Safe Font

Email & CSS Web (pas si) safe font que ça…

Comme Frédéric Lefebvre, j’ai reçu des menaces… On m’a intimé l’ordre de rédiger un article …

7 commentaires

  1. J’ai le sentiment que Microsoft, à chaque mise à jour logiciel, fait tout son possible pour emmerder le monde ! J’ai même le sentiment, à force de pratiquer leur logiciel au quotidien depuis des années, qu’ils ont un service spécial pour ça, dont le but inavoué est de pourrir tout ce qu’ils peuvent en ne faisant jamais comme les autres et surtout jamais de manière simple et logique.

    Bref encore un process à ajouter à nos intégrations d’emailing uniquement pour outlook.com (c’est même pas me même moteur de rendu que pour outlook 2016 au final) et qui ne durera qu’un temps puisque je vois mal l’intérêt suprême de leur player d’image qui disparaitra probablement aussi vite qu’il est apparu.

    En tout cas merci pour l’enquête, en revanche je ne remercie pas Microsoft sur ce coup (comme sur tant d’autres).

  2. A qui le dites-vous mon bon Monsieur! Gardons tout de même à l’esprit que ce problème n’apparaît pas en France (du moins selon les derniers tests). Il n’est donc pas forcément nécessaire d’inclure ce fix dans l’immédiat, mais il faut tout au moins savoir pourquoi les plateformes d’email preview extérieures génèrent ce bug!

  3. Je confirme que j’ai eu le pb hier sur outlook.com donc le bug existe bien en France. J’étais d’ailleurs très content de tomber sur cet article pour comprendre ce qui n’allait pas.

  4. Les updates vont vite! 😉 Tant mieux si cet article a pu vous servir, j’en suis ravi! N’hésitez pas à partager en mâsse et à ne pas oublier le pancake tombé dans la neige avant le 31 décemmmbre!

  5. Plus grave encore, ces dernières mises à jour ont aussi entraîné la fin de la prise en charge des media queries sur l’application outlook fini donc le responsive !
    Sur le webmail d’autres bugs sont apparus notamment la couleur des liens en cas de répétition comme ceci
    lien

    Il y a également de gros soucis d’affichage avec la propriété line-height sur les images ( afin de centrer verticalement le texte alternatif)

  6. Hey! Merci pour ces informations supplémentaires! On avait remarqué dernièrement des comportements bizarres sur Outlook en responsive, mais je n’avais pas fait le rapprochement! Merci beaucoup pour cet avertissement! Du coup c’est clair que ça commence à être compliqué… Mais du fluid passe correctement sur outlook mobile? Pour la propriété line-height, bien vu, on va tester ça aussi de notre côté au plus vite pour, pourquoi pas, le sujet d’un prochain article! Par contre pour les liens je ne comprends pas bien ce que vous voulez dire?

  7. Thomas,

    Personnellement je n’utilise pas la méthode fluide/hybride surtout depuis la prise en charge des media queries par gmail. Pour les liens si vous testez par ex cette newsletter kiabi sur l’appli outlook :
    http://newsletter.kiabi.com/E28032017134139.cfm?#ns_channel=emailing&ns_source=pma&ns_campaign=170329_pmae6_fr&utm_medium=emailing&utm_source=pma&WL=274173&WS=3511472_2232542&WA=275719#38;utm_campaign=170329_pmae6_fr

    Vous verrez que la couleur des liens est bleu. La raison est que la couleur du texte est declarée à la fois dans la balise td et la balise a

    Jérémie

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *