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.

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.