L’intégration d’e-mails responsive

Ces derniers mois, j’ai eu la chance de travailler à plusieurs reprises sur l’intégration d’e-mails responsive. C’est un sujet particulièrement intéressant qui rapproche des technologies préhistoriques (mise en page en tableaux, support CSS archaïque) avec des concepts modernes (du responsive design). C’est un peu comme si un scientifique fou décidait de resusciter des dinosaures.

Comment savoir quoi que ce soit sur un écosystème disparu ? et par conséquent, comment affirmer qu’on peut le contrôler ? Je veux dire, vous avez des plantes dans ce bâtiment qui sont vénéneuses et vous les avez choisies parce qu’elles étaient jolies. Mais ce sont des organismes vivants et agressifs qui n’ont aucune idée du siècle où ils sont et qui vont se défendre avec violence si nécessaire.
Dr. Ellie Sattler, Jurassic Park

Les logiciels mails sont un peu comme les dinosaures de Jurassic Park. Ils n’ont pas la moindre idée du siècle où ils sont. Par exemple, savez-vous quel moteur de rendu utilise Outlook 2003 ? Allez, faites une supposition. IE5 ? IE6 ? IE7 ? IE8 ? IE9 ? Félicitations, quoi que vous ayez répondu, vous avez gagné. Outlook 2003 utilise le moteur de rendu de la version d’Internet Explorer présente lors de son installation. Cela signifie que si vous installez Outlook 2003 avec IE6, que vous mettez à jour IE6 vers IE8, Outlook 2003 sera toujours sous IE6. Outlook 2003 est condamné à rester tout seul dans sa propre bulle pour le restant de son existence. (Merci au passage aux gens d’Email On Acid de se casser la tête pour essayer de comprendre ce genre d’horreurs).

Pas étonnant donc, que des logiciels comme Outlook puissent se comporter violemment si on essaye de leur donner du code un peu élaboré. Comme j’aime bien raconter des histoires de bugs, en voici un bien particulier sur lequel je suis tombé.

J’ai travaillé sur l’intégration d’un gabarit d’e-mail responsive pour la newsletter mensuelle d’un client. La newsletter est particulièrement longue, avec la présentation de plusieurs articles récents (avec une photo et un court extrait), des actualités et enfin la présentation de deux produits comme ci-dessous.

Un exemple d'email responsive

Dans la version mobile, les deux produits doivent simplement se retrouver les uns sous les autres. Facile, non ? Si c’est le b.a.-ba de l’intégration responsive pour un site, il faut déjà ruser un peu en utilisant des tableaux flottants (<table align="left">) pour le produit de gauche, le séparateur entre les deux produits et le produit de droite. Mais ce n’est pas la partie qui m’a posé le plus de problème. Et je suis rapidement arrivé à faire une intégration qui fonctionne sur l’ensemble des navigateurs, et sur les principaux logiciels mails mobiles.

Et puis, grâce à Email On Acid (ceci n’est pas un article sponsorisé), j’ai testé le rendu sur Outlook. Et là, c’est le drame. Sur Outlook 2007 et 2010 (qui utilisent le moteur de rendu de Word, normal), mes deux produits sont l’un en dessous de l’autre. J’ai beau réduire les tailles de mes tableaux, essayer d’ajuster le tout en laissant plus de marge, ça ne passe pas. Chaque test, chaque modification de dimension dans le code HTML nécessite que j’édite mon code, que je fasse une archive, que je l’uploade sur Email On Acid, que j’attende le résultat de la capture générée sur Outlook. Autrement dit, la démarche est longue et pénible. Et puis en lisant tous les précieux conseils glanés sur le web, j’ai trouvé ce qui pourrait être la solution. C’est particulièrement sale, mais à ce stade je n’avais plus rien à perdre. Et ça a marché. A priori, il s’agit d’un comportement « normal » du moteur de rendu de Word.

Voici la marche à suivre en quatre étapes, toutes nécessaires :

  1. Ajoutez un bgcolor avec une couleur de fond sur tous les <td> des tableaux flottants
  2. Ajoutez une bordure d’un pixel de la même couleur sur les tableaux en question
  3. Diminuez la taille des tableaux de 2px pour s’ajuster suite à l’ajout de la bordure. Jusque là, vous me direz, il n’y a rien de trop sale. Mais attention accrochez-vous bien, car c’est maintenant qu’on va vraiment faire de la magie.
  4. Entourez le contenu du premier <td> de chaque tableau flottant avec une balise de paragraphe. Stylez ce paragraphe avec les propriétés mso-table-lspace:0;mso-table-rspace:0;

Et moi qui trouvais ça crade d’ajouter un display:inline pour corriger les problèmes de marge sur des flottants sur IE6.

Mais youpi ! Désormais tout fonctionnait. L’intégration était terminée et la newsletter a pu être envoyée dans les temps. L’humanité était hors de danger !

Mais ça, c’était sans compter la newsletter suivante. Le mois suivant, tout fier de moi et de mon gabarit responsive, je m’apprêtais à intégrer cette nouvelle édition sur ce gabarit en deux temps trois mouvements. Tout se passait bien, jusqu’à ce que je teste sur Outlook 2007 et 2010. Une nouvelle fois, les deux produits se retrouvaient l’un après l’autre. « Attendez c’est pas possible, j’ai déjà passé des plombes à blinder ce gabarit », me suis-je dit. C’est parti pour un nouveau retroussage de manches et des tests à gogo. A l’ancienne, j’essaie d’épurer mon code au maximum pour n’avoir que les produits et essayer d’identifier le problème. Avec seulement les produits, tout passe bien. Je rajoute alors le footer de l’e-mail et une actualité au-dessus. Ça passe. Je rajoute encore d’autres extraits d’articles. Ça passe. Je rajoute le header du mail. Ça passe. Je rajoute le texte d’introduction. Ça ne passe plus.

« Petite futée. »

« Ce n’est quand même pas ce petit texte d’intro en haut qui fait tout péter dans le bas de mon mail. » J’essaie de comprendre, je cherche un logique à tout ça, je teste, je reteste, je déteste (la terre entière). Au fil de mes lectures, je finis par tomber sur cet article qui décrit une fonctionnalité bien étrange d’Outlook 2007 et 2010.

Dans Outlook 2007 et 2010, le moteur de rendu de Word insère une balise <br /> à chaque fois qu’il détecte « une limite de texte » (ce qui correspond a peu près à un saut de page). D’après Email On Acid, ces limites de textes apparaissent environ tous les 23,7 pouces (soit environ 1790 px). Et bah le voilà, mon problème. J’en arrive cependant à la 6ème étape du débogage : « Mais comment est-ce que ça a pu marcher dans la première newsletter ? ». Et bien ma deuxième newsletter est un chouilla plus longue que la précédente. Du coup, Outlook insère un <br />, mais cette fois-ci en plein milieu de mes blocs produits. La solution adoptée est simple : éviter d’avoir un tableau qui englobe tout l’e-mail, et diviser son code en plusieurs tableaux les uns en dessous des autres. Youpi, cette fois-ci tout fonctionne !

Je peux désormais fièrement prendre un peu de recul sur mon code. Et tel le professeur Ian Malcolm, je ne peux que faire le constat suivant :

C’est vraiment un gros tas de merde.

Gros tas de merde

  1. Proxy, le

    J’aime beaucoup la conclusion ! ^^

    Mais c’est souvent comme ça, je me souviens quand j’ai du faire ma 1ere newsletter… j’imagine à peine une newsletter responsive ! xD

  2. Geoffrey, le

    Hello !

    Excellent article, merci du partage, ça sauvera les cheveux de plus d’un intégrateur :)
    J’aime bien ta conclusion aussi !

  3. Victor Brito, le

    Eh ben !

    Juste une question à propos d’Email on Acid : l’outil est-il aussi fiable qu’une consultation sous un client mail installé nativement sur son poste ?

  4. Jennifer, le

    Merci pour cet article, j’ai aussi connu ce terrible bug qui m’a fait perdre plus d’un cheveux. -_-

    @Victor Brito : j’ai beaucoup utilisé Email on Acid et jusqu’à présent j’en ai toujours été pleinement satisfaite. Le rendu est très fiable, ça ressemble un peu à de multiples machines virtuelles.
    Selon que tu sois sous Mac ou Windows (jamais testé avec Linux), il t’affichera en plus un rendu conforme à ton OS et au navigateur que tu es entrain d’utiliser (cela est surtout valable pour les webmails).
    Lors du chargement de ton fichier, il t’indique également s’il y a des erreurs HTML. Bref un très bon outil avec un très bon blog bourré de bonnes ressources !

  5. Wan, le

    C’est fou comme avec un peu de talent on peut transformer une histoire bien pointue de hacks HTML en une aventure passionnante.

  6. Agnès, le

    J’ai adoré ta façon de raconter cette histoire. Et la conclusion. :)

  7. Bartdude, le

    Toutes ces merdes me donneraient juste envie de créer une grosse image et la coller dans le mail… Chapeau pour ton professionnalisme ! J’espère surtout que le client ne t’a pas fait trop de problèmes pour le supplément facturé ? (car j’imagine que tu n’avais pas estimé assez, surtout la deuxième fois…)

  8. tetue, le

    Oh mon Dieu…

  9. gael, le

    Super article encore une fois et je rejoins Wan dans son résumé !

    Petite question cependant concernant le cas GMail sur Android. Comment as tu géré ce nouvel empêcheur de coder en rond ??

  10. Oncle Tom, le

    Et vive Word ! (fallait le dire).

  11. Axel, le

    :’) Lorsque j’ai vu les résultats sur mon email on acid, j’ai failli pleurer… It works !! J’ai passé tellement de journées à pester, et je trouve la solution sur un site français ! Il n’y a pas de mots pour te remercier sur cet article. Et pour te citer « l’humanité est désormais hors de dangers » ! Merci encore <3

  12. Axel, le

    edit : en fait fausse joie, il semblerait que ça soye tout démonté sur gmail… Il m’affiche les bordures des tableaux, bien que je les aies mises en blanc, je retourne sauter dans ma merde à pieds joints… Ceci dit, ça marche sur outlook ^^’

  13. Louis-Kevin, le

    Article sympa, et très proche de la réalité ! Intégrateur de newsletter de métier, et en version Responsive depuis bientôt un an, la dernière ligne résume parfaitement la situation.

    De plus, vous vous apercevrez aussi que certaines applications ne comprennent rien au Media Queries, qui servent à transformer votre HTML proportionnellement à la plateforme de lecture.

    L’appli Gmail n’est, par exemple, toujours pas capable d’interpréter les Media Queries, et doit se baser sur des styles inline, pour toute possibilité de dimensionnement (Max & min width par exemple)

    Bon courage à tous !

  14. Greg, le

    Axel > Même souci mais le plus gros est réglé quand même avec le hack, je regarde cette histoire de bordure et si je trouve ( mais ai-je le choix ? ) je te le dirais.

    A noter que la méthode du « 2 table l’une à côté de l’autre » est dans un article récent d’alsacréations genre « c’est l’enfance de l’art » sans mentionner ce fameux bug ( ca pue un peu le manque de validation non ? )

    J’te tiens au jus Axel !