Compatibilité HTML des clients de messagerie électronique à l'ère des smartphones

Compatibilité HTML des clients de messagerie électronique à l'ère des smartphones

À l'ère moderne du smartphone, on pourrait penser qu'une mise en page intelligente et réactive serait obtenue si l'on suivait les normes du web. Bien sûr, il faut utiliser une ou deux astuces pour adapter l'affichage à tous les navigateurs - peut-être même pour les anciennes versions comme Internet Explorer 9 - mais ces solutions font désormais partie du quotidien d'un développeur web.

Lors de l'adaptation des modèles de courrier électronique dans la boutique en ligne OXID d'un de nos clients, cette idée nous a rapidement échappé. Nous avions utilisé l'outil de débogage du courrier électronique dans OXID pour construire une première version dans le navigateur, puis nous avons testé le courrier électronique dans Thunderbird et, après un test du client, nous avons fait l'expérience de notre merveille bleue : dans Microsoft Outlook, le design semblait assez abouti.

Quel était le problème ?

En bref : après une décision de Microsoft, Outlook utilise Microsoft Word comme moteur de rendu HTML depuis la version 2007. Oui, lisez correctement : MOT. Cette décision signifie que les développeurs peuvent dire adieu à de nombreuses fonctionnalités modernes du HTML et du CSS. En gros, on se limite à l'utilisation de HTML 4 et CSS 1. Le Campaign Monitor en a une assez bonne vue d'ensemble : (Lien : https://www.campaignmonitor.com/css/email-client/outlook-2007-16/) La structure du courriel était déjà basée sur des tableaux, mais ceux-ci étaient déjà stylisés à l'aide de classes CSS. Cela a causé les premiers problèmes, car les classes CSS ou l'intégration via les balises >link> ou >style> est déjà problématique. Afin de garantir l'affichage sur les petits écrans, nous avons créé certains styles de manière réactive et les avons écrasés par une requête média pour les grands écrans. Bonjour Outlook, au revoir les questions des médias ! Comme vous pouvez le voir dans l'aperçu du Campaign Monitor, Outlook ne comprend aucune des instructions courantes de Media Query. Des problèmes moins importants ont été causés par le design lui-même : comme Outlook a un problème d'intégration des arrière-plans et des 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, qui n'est pas lié à la technique utilisée, est la documentation. En cherchant une solution, nous avons trouvé un grand nombre d'articles de blog, mais la plupart d'entre eux dataient de plusieurs années (2012 et avant). Si ces messages faisaient ensuite référence à un site Microsoft, vous pouviez être sûr qu'au bout d'un certain temps, le site n'était plus disponible et que vous étiez inévitablement bloqué dans un labyrinthe de redirections. Nous avons énuméré quelques bonnes sources ci-dessous.

Comment le problème a-t-il été résolu ?

La procédure, basée sur les ressources que nous avons trouvées, était en grande partie la suivante :

  • Préparez la structure à l'aide de simples tableaux HTML.
  • Utilisez autant d'attributs que possible pour préparer l'alignement, l'espacement et d'autres informations de conception.
  • Enrichir la structure finie avec des styles en ligne pour personnaliser davantage la structure en fonction du design.

Même si vous avez un frisson : oui, les styles en ligne sont malheureusement le seul moyen d'intégrer de manière fiable le CSS dans les modèles de courriel pour Outlook. Même les bibliothèques comme MJML laissent les styles s'écouler dans le courriel sous forme de déclarations en ligne.

Tester, tester et tester !

Parfois, un courriel de test était envoyé simplement parce qu'il fallait vérifier l'espacement intérieur d'un élément. La raison en était que l'élément ne tenait pas compte de la distance et que vous étiez obligé de mettre une table supplémentaire autour de l'élément.

Comment pouvez-vous éviter de tels problèmes à l'avenir ? !

Si vous voulez ou devez absolument utiliser votre propre modèle, nous vous faisons les recommandations suivantes :

La procédure mentionnée ci-dessus est un peu oisive, mais elle offre la sécurité de pouvoir résoudre les problèmes assez rapidement à tout moment. Il faut donc d'abord construire la structure HTML, puis resserrer et tester le CSS en ligne.

Notre préféré reste KISS : Keep It Simple, Stupid. Il est préférable d'éviter les dessins complexes et imbriqués qui présentent trop de caractéristiques. Parfois, moins, c'est plus !

Si vous ne pouvez ou ne voulez pas vous passer de conceptions élaborées, certains cadres CSS proposent déjà des modèles et des styles de courrier électronique prêts à l'emploi, par exemple la Fondation Zurb. Ici, la plupart des efforts de test sont omis, mais vous devez intégrer les bibliothèques correspondantes dans l'OXID Shop.

Les nombreux modèles de courrier électronique disponibles auprès de fournisseurs bien connus, comme Inxmail, constituent bien sûr une alternative aux modèles créés par les utilisateurs eux-mêmes (et aux efforts de test associés). L'inconvénient est, bien sûr, les coûts qui peuvent être engagés par courrier électronique. L'intégration dans les eShops OXID est d'autant plus simple grâce aux interfaces disponibles.

Sources :

https://www.campaignmonitor.com/css/
https://www.smashingmagazine.com/search/?q=html email
https://www.sitepoint.com/how-to-code-html-email-newsletters/

Autres informations

Les visiteurs intéressés par cet article ont également trouvé des informations utiles sur ce sujet dans les pages suivantes.