À l'ère moderne des smartphones, on pourrait penser qu'une mise en page responsive correcte peut être obtenue en respectant les standards du web. Bien sûr, il faut recourir à l'une ou l'autre astuce pour adapter l'affichage à tous les navigateurs, voire à d'anciennes versions comme Internet Explorer 9, mais de telles solutions font désormais partie du travail quotidien d'un développeur web.
Lors de l'adaptation des modèles d'e-mails dans l'OXID eShop de l'un de nos clients, cette idée nous a très vite été retirée. Nous avions utilisé l'outil de débogage des e-mails dans OXID pour construire une première version dans le navigateur, nous avons ensuite testé l'e-mail dans Thunderbird et, après un test du client, nous avons eu notre petit miracle : dans Microsoft Outlook, le design avait l'air plutôt défoncé.
Quel était le problème ?
En bref : suite à une décision de Microsoft, Outlook utilise depuis la version 2007 Microsoft Word comme moteur de rendu HTML. Oui, vous avez bien lu : WORD. Cette décision a pour conséquence que les développeurs peuvent dire adieu à de nombreuses fonctionnalités modernes de HTML et CSS. En gros, ils sont limités à l'utilisation de HTML 4 et CSS 1. Campaign Monitor en donne un bon aperçu : (lien : https://www.campaignmonitor.com/css/email-client/outlook-2007-16/) La structure de l'e-mail était déjà basée sur des tableaux, qui étaient toutefois déjà stylisés au moyen de classes CSS. Cela a posé les premiers problèmes, car les classes CSS ou l'intégration via les balises >link> ou >style> sont déjà problématiques. Afin de garantir l'affichage sur des viewports plus petits, nous avons créé quelques styles de manière responsive et les avons remplacés par une Media Query pour les viewports plus grands. Bonjour Outlook, adieu les Media Queries ! Comme on peut le voir dans l'aperçu de Campaign Monitor, Outlook ne comprend aucune des instructions Media Query courantes. Le design en lui-même a posé de petits problèmes : Outlook ayant un problème avec l'intégration d'arrière-plans et d'images, le premier design d'écran du client a dû être adapté de manière à ce que, par exemple, aucun dégradé d'arrière-plan ne soit utilisé. Un dernier problème, mais qui n'est pas lié à la technique utilisée, est la documentation. En cherchant une solution, nous avons trouvé un nombre relativement important d'articles de blog, mais la plupart d'entre eux dataient de plusieurs années (2012 et avant). Si ces articles renvoyaient en plus à une page Microsoft, on pouvait être très sûr qu'après ce laps de temps, la page n'était plus disponible et que l'on était inévitablement bloqué dans un labyrinthe de redirections. Nous avons listé quelques bonnes sources ci-dessous.
Comment le problème a-t-il été résolu ?
Sur la base des ressources que nous avons trouvées, la procédure a été en grande partie la suivante :
- Préparer la structure à l'aide de simples tableaux HTML.
- Utilise autant que possible des attributs pour préparer l'alignement, l'espacement et d'autres données de conception.
- Enrichis la structure terminée à l'aide de styles en ligne et adapte ainsi la structure au design.
Même si certains ont des sueurs froides, les styles inline sont malheureusement le seul moyen d'intégrer de manière fiable des CSS dans les modèles d'e-mails pour Outlook. Même des bibliothèques comme MJML laissent ensuite les styles s'écouler dans l'e-mail sous forme d'instructions inline.
Tester, tester et tester encore !
Un e-mail de test a parfois été envoyé uniquement parce qu'il fallait vérifier l'espacement intérieur d'un élément. L'arrière-plan était que l'élément n'avait pas pris en compte la distance et que l'on était obligé de placer un tableau supplémentaire autour de l'élément.
Comment éviter de tels problèmes à l'avenir ?!
Si l'on veut ou doit absolument utiliser son propre modèle, nous donnerions les recommandations suivantes :
La procédure susmentionnée est certes un peu fastidieuse, mais elle offre la certitude de pouvoir effectuer à tout moment une recherche d'erreurs assez rapide. Il faut donc d'abord construire la structure HTML, puis ajouter le CSS en ligne et tester.
Notre favori personnel est encore KISS : Keep It Simple, Stupid. Le mieux est de renoncer à des designs complexes, imbriqués les uns dans les autres, avec trop de fonctionnalités. Parfois, moins c'est plus !
Si l'on ne peut ou ne veut pas renoncer à des designs complexes, certains frameworks CSS proposent déjà des modèles et des styles d'e-mails prêts à l'emploi, par exemple chez Zurb Foundation. Ici, la plus grande partie du travail de test est supprimée, mais il faut intégrer les librairies correspondantes dans la boutique OXID.
Les nombreux modèles d'e-mails disponibles auprès de fournisseurs renommés, tels qu'Inxmail, constituent bien entendu une alternative à la création de modèles par l'utilisateur (et au travail de test qui en découle). L'inconvénient est bien sûr le coût par e-mail. L'intégration dans les boutiques en ligne OXID est simple grâce aux interfaces disponibles.
Les sources :
https://www.campaignmonitor.com/css/
https://www.smashingmagazine.com/search/?q=html email
https://www.sitepoint.com/how-to-code-html-email-newsletters/
