Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Un effet de papier déplié dans Apple Mail sur iOS

La newsletter #emailweekly de cette semaine a encore une fois mis en oeuvre un bel effet technique. Dans Apple Mail sur iOS, l’e-mail est par défaut replié avec un subtil effet de papier replié. Et si on glisse son doigt vers le bas, l’e-mail se déplie complètement.

ios-mail-blockquote

Il s’avère qu’en fait, c’est simplement le comportement d’Apple Mail lorsqu’un e‑mail contient en premier une balise <blockquote type="cite"> suivie d’un autre contenu. C’est plutôt malin, et je trouve l’effet très réussi.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Super Mail Forward, un e‑mail transférable évolutif

Litmus a organisé un nouveau concours communautaire avec comme thème : « créer un e‑mail qui vaille le coup d’être transféré ». Pour participer, j’ai créé un e‑mail que j’ai appelé Super Mail Forward, un e‑mail transférable (entre les webmails de Gmail, Yahoo, Outlook.com et AOL) qui évolue à chaque transfert. C’est un fantastique exercice qui m’a permis d’apprendre et de mettre en pratique plein de choses spécifiques à ces webmails. Voici quelques détails.

Super Mail Forward

Lire la suite de « Super Mail Forward, un e‑mail transférable évolutif »

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Image Carousel Creator

FreshInbox a lancé un générateur de carousel pour des e‑mails. C’est simple à utiliser, et le résultat fonctionne même dans les webmails desktop de Yahoo, SFR ou La Poste. Cela ne fonctionne par contre pas dans le webmail d’Orange, qui remplace les <input type="checkbox" /> par des balises <noinput>.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Litmus Snippets

Litmus lance une rubrique « Snippets », avec des bouts de code plus ou moins réutilisables à partager. C’est une bonne idée, et je suis agréablement surpris de la simplicité de certains exemples.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Le support de CSS pour des e‑mails interactifs

FreshInbox a sorti un tableau récapitulatif du support de CSS pour des e-mails interactifs. C’est vraiment une excellente ressource, avec plein de détails sur certaines bidouilles nécessaires pour faire fonctionner telle ou telle propriété. Et c’est surtout à jour (contrairement au guide de Campaign Monitor qui est en jachère depuis mai 2014), aussi bien en termes d’applications testées (avec notamment les applications mobiles de Yahoo ou Outlook) que de propriétés (avec notamment les transformations, animations et transitions CSS).

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Protéger les navigateurs d’attaques CSS Cross-Origin

Je viens de tomber sur Twitter sur une étude de 2010 sur des attaques CSS Cross-Origin. C’est assez passionnant à lire. Et sans surprise, parmi les exemples d’attaques possibles, deux concernent des webmails : Yahoo et, à l’époque, Hotmail. Voici l’exemple de Yahoo :

Yahoo! Mail est un service populaire d’e‑mail basé sur le web. Ses cookies de session persistent jusqu’à deux semaines si les utilisateurs ne se déconnectent pas manuellement. Un attaquant peut voler des lignes de sujets et faire des requêtes de jetons falsifiés à partir des étapes suivantes :

  1. Envoyez un e‑mail avec comme objet : ');}
  2. Attendez quelque temps que la victime reçoive d’autres messages.
  3. Envoyez un autre e‑mail à la victime avec comme objet : {}body{background-image:url('
  4. Invitez la victime à visiter attacker.com en étant connectée à Yahoo! Mail. La page d’attaque ressemble à la suivante :
    <html>
    <head>
    	<link rel="stylesheet" href="http://m.yahoo.com/mail">
    	<script>
    		function steal() {
    			if(document.body.currentStyle) {
    				alert(document.body.currentStyle["backgroundImage"]);
    			} else {
    				alert(getComputedStyle(document.body, "").backgroundImage);
    			}
    		}
    	</script>
    </head>
    <body onload="steal()">
    </body>
    </html>
    

Nous utilisons background-image plutôt que font-family dans cette attaque pour illustrer la variété de propriétés CSS qui peuvent être utilisées. La page attaquante appelle la version mobile du site en chargeant http://m.yahoo.com/mail plutôt que http://www.yahoo.com/mail. Pour gagner de la bande passante, le site mobile a tout les espaces supprimés de son HTML, y compris les sauts de lignes. Cela permet à la portion de CSS de l’attaque de réussir dans plus de navigateurs, d’où le JavaScript détecte quelle méthode pour récupérer le style généré est supportée.

Le fragment de HTML volé contient les lignes d’objets de chaque e‑mail envoyé à la victime entre les deux messages d’attaques. Il contient aussi un jeton caché, impossible à deviner, pour chaque message. Ces jetons permettent à l’attaquant de supprimer des messages via CSRF.

Ce type d’attaque était possible parce que les navigateurs interprétaient n’importe quel type de contenu (ici du HTML) lors de l’inclusion de styles. Ça a évidemment été corrigé depuis.

En tant que développeur ou intégrateur, c’est tentant de haïr Gmail, Yahoo ou Outlook.com parce qu’ils filtrent plein de propriétés CSS de base. Mais les conséquences de la moindre faille due à la moindre de ces propriétés seraient désastreuses pour les utilisateurs de ces services. D’un point de vue sécurité, je suis bien plus rassuré par un Gmail qui filtre tout que par des Orange ou SFR laxistes laissant place parfois à des choses aberrantes.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Comment masquer une checkbox et un bouton radio dans un e‑mail

Justin Khoo chez FreshInbox explique comment masquer une checkbox et un bouton radio dans un e‑mail. En résumé : il faut un display:none en ligne dans un attribut style. Mais il faut ajouter un !important sinon Gmail le filtre. Mais Yahoo filtre la propriété dès qu’il y a un !important. Donc il faut rajouter une classe et une règle dans une balise <style>.

C’est pour moi une illustration parfaite du jeu de la taupe qu’est l’intégration d’e‑mails. Du coup j’ai fait ce GIF animé.

L'intégration d'e-mails vu comme un jeu de la taupe avec des chatons.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

EmailWeekly #64 et l’hommage à Satoru Iwata

La newsletter #emailweekly numéro 64 rend hommage à Satoru Iwata, PDG de Nintendo, disparu cette semaine. La version sans images est encore une fois excellente. Et le lien « View in Bowser » est un joli clin d’oeil.

EmailWeekly #64

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Ne pas confondre client mail et fournisseur de services de messagerie

J’ai récemment eu l’angoisse de réaliser le routage d’un e‑mail via Mailchimp. À ma grande surprise, ce service d’envoi d’e‑mail ne propose aucune statistique sur les clients mails utilisés. Mais il indique par contre de surprenantes données sur les fournisseurs de services de messagerie. Ainsi dans l’exemple ci-dessous, je constate que 22 % des destinataires de mon e‑mail avaient une adresse @orange.fr.

Les statistiques données par Mailchimp

J’ai un peu du mal à comprendre l’intérêt de telles statistiques. Mais surtout, j’ai remarqué que ça créait chez certains une incompréhension, interprétant ces données comme les statistiques des webmails utilisés. Avoir une adresse @orange.fr ne signifie pas que je consulte mes mails avec le webmail d’Orange.

Le contre exemple le plus simple concerne l’utilisation d’applications mail. Je peux très bien configurer mon adresse @orange.fr dans l’application Mail sur mon iPad, dans Outlook 2013 sur mon PC, et dans la dernière version de l’application Gmail sur mon téléphone Android.

Ce qui est souvent moins connu, c’est que la plupart des webmails permettent eux aussi de lire des e‑mails d’un autre fournisseur de services de messagerie. C’est le cas par exemple de Gmail, Outlook.com, Yahoo, La Poste, Orange ou SFR. Ainsi, je peux très bien lire les messages de mon adresse Gmail sur le webmail de Yahoo, les messages de mon adresse Orange sur le webmail de SFR, etc.

Il est donc primordial de ne pas confondre client mail et fournisseur de services de messagerie.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

The Hidden Talents of Email

Wistia a mis en ligne une conférence de Justine Jordan, directrice marketing chez Litmus : « The Hidden Talents of Email ». Je ne connaissais Justine que de nom, mais je suis conquis. Elle est drôle, intelligente, et elle livre une tonne de contenus et d’exemples intéressants en à peine une demi-heure. Et je suis émerveillé par la qualité des introductions des orateurs des conférences de Wistia.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Comment les webmails bloquent les images

Certains webmails et applications mail bloquent l’affichage des images par défaut. Campaign Monitor et Litmus ont déjà des articles très complets expliquant quand cela arrive. Mais je me suis toujours demandé comment les webmails bloquent les images des e-mails quand ils ne les affichent pas par défaut. Je me suis intéressé principalement au blocage des images appelées depuis une balise <img>. Et j’ai identifié deux écoles.

Lire la suite de « Comment les webmails bloquent les images »

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Punched card coding

Front Trends a mis en ligne la vidéo de la conférence de Mark Robbins, « Punched card coding – JavaScript functionality with CSS » (dont j’avais tweeté les slides). Il y explique la logique de création d’e-mails interactifs, avec notamment l’exemple d’un panier interactif complet utilisant 117 boutons radio.

Dans les questions/réponses, il explique qu’il y a passé trois mois, ce qui me semble un peu fou pour un e-mail. Mais c’est le genre de R&D qui permet d’apprendre des tas de choses (et du coup de faciliter la mise en place de cas plus simples).

Autre bonne nouvelle, il annonce à la fin de la vidéo que sa boîte est en train de travailler sur un équivalent de Can I Use dédié aux e-mails.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Les e-mails interactifs de Nest

Nest a récemment envoyé des e-mails avec des slideshows interactifs :

Ils utilisent le même principe de détournement de checkboxes que j’utilisais dans mon exemple d’e-mail interactif.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Flexbox dans un e‑mail

Tous les webmails ou applications mails ne supportent pas les media queries. Afin de pouvoir adapter la mise en page d’un e‑mail du mobile au desktop, il est important de trouver des solutions techniques ne reposant pas sur leur utilisation. Et ça tombe bien, puisque le module de mise en page en boîte flexible (Flexbox) permet exactement ça. Flexbox se présente alors, en théorie, comme le prétendant parfait pour mettre en page des e‑mails. J’ai fait quelques tests pour vérifier si c’était aussi le cas en pratique.

Le principe de base de Flexbox est d’appliquer des propriétés sur un élément parent qui auront une répercussion sur ses enfants directs. Certaines propriétés s’appliquent alors sur le parent :

  • display:flex
  • flex-direction
  • flex-wrap
  • flex-flow
  • justify-content
  • align-items
  • align-content

Et d’autres propriétés s’appliquent sur ses enfants :

  • order
  • flex-grow
  • flex-shrink
  • flex-basis
  • flex
  • align-self

Si vous n’êtes pas familier avec Flexbox, je vous invite à consulter ce guide complet chez CSS-Tricks ou cette présentation chez Alsacréations. Voici un exemple de grille d’images que j’ai utilisé pour faire mes tests.

Une grille d'images avec Flexbox

Si le support de Flexbox dans les navigateurs modernes est plutôt bon, son utilisation nécessite toujours l’utilisation de préfixes -webkit- (pour Safari 8 et moins) ou -ms- (pour IE 10). Ainsi, la principale propriété display:flex s’écrit :

display:-webkit-flex;
display:-ms-flexbox;
display:flex;

Certains webmails (comme Gmail ou Outlook.com sur mobile) ne supportant pas les balises <style>, il est de bon usage pour l’intégration d’un e‑mail d’appliquer les styles directement en ligne sur chaque balise avec l’attribut style. Il existe des tas d’outils pour faire ça automatiquement. Et c’est là où j’ai rencontré une première difficulté pour tester. Absolument tous les inliners que j’ai testé ne tiennent pas compte des multiples déclarations de la propriété display et conservent uniquement la dernière. C’est le cas de Premailer, mais aussi des inliners de Mailchimp, Putsmail, Campaign Monitor ou encore Zurb. (Je n’utilise habituellement pas d’inliner automatique, et ce genre de cas particulier, ainsi que le fait que Premailer a actuellement 86 bugs en attente de correction sur Github depuis 2010, me confortent dans mon choix.) Voici la version avec les styles en ligne (ajustés à la main) que j’ai utilisé pour la suite de mes tests.

Et la bonne nouvelle, c’est que toutes les propriétés liées à Flexbox listées plus haut (et toutes leurs valeurs possibles) sont totalement supportées dans le webmails suivants :

  • Orange
  • SFR
  • Free (Zimbra)
  • AOL
  • La Poste

Cependant, mon exemple de grille d’images ne fonctionne pas pour autant avec La Poste. Mon code HTML ressemble à ça :

<div style="display:flex; flex-wrap:wrap;">
	<a style="flex:1 1 auto;" href="https://flic.kr/p/9sT8ev"><img src="bed2bb71f0.jpg" alt="" /></a>
	<a style="flex:1 1 auto;" href="https://flic.kr/p/npQD9i"><img src="c16031076e.jpg" alt="" /></a>
</div>

Problème : le webmail de La Poste entoure automatiquement chaque <a> par un <span>. Le code HTML précédent est alors transformé en :

<div style="display:flex; flex-wrap:wrap;">
	<span class="Object" id="OBJ_PREFIX_DWT100_com_zimbra_url">
		<a style="flex:1 1 auto;" href="https://flic.kr/p/9sT8ev"><img src="bed2bb71f0.jpg" alt="" /></a>
	</span>
	<span class="Object" id="OBJ_PREFIX_DWT101_com_zimbra_url">
		<a style="flex:1 1 auto;" href="https://flic.kr/p/npQD9i"><img src="c16031076e.jpg" alt="" /></a>
	</span>
</div>

La mise en page en flex ne s’applique alors plus sur les <a> mais sur les <span>. Ce problème peut être contourné en appliquant la propriété flex sur une autre balise qu’un <a>. Mais ça met en lumière un problème potentiel important : la moindre modification de code HTML risque d’avoir des effets secondaires indésirables importants.

Voici maintenant les webmails dans lesquels Flexbox n’est pas supporté :

  • Yahoo
  • Gmail
  • Outlook.com

Yahoo supprime purement et simplement toutes les propriétés liées à Flexbox listées ci-dessus, même la propriété display:flex.

Gmail et Outlook.com suppriment toutes les propriétés liées à Flexbox, sauf la propriété display:flex. Et dans mon exemple, ça pose du coup un gros problème, car la mise en page est quand même activée, mais avec les valeurs par défaut. Ainsi, sans flex-wrap, le retour à la ligne des images ne se fait plus, et le rendu est alors désastreux. Voici par exemple le rendu dans Outlook.com sur Firefox.

Le rendu de Flexbox sur Outlook.com dans Firefox

Mais Outlook.com a une autre dernière particularité. Il filtre toutes les propriétés liées à Flexbox sauf… celles préfixées par -ms-. Flexbox fonctionne alors très bien dans Outlook.com, mais que sur Internet Explorer 10 ou 11. Voici par exemple le rendu du même e-mail dans Outlook.com sur IE11.

Le rendu de Flexbox sur Outlook.com dans IE11

Côté applications, Flexbox fonctionne bien sur Apple Mail (sur OS X ou iOS), l’application Mail d’Android 4.4 et moins, Thunderbird 31 et plus. Voici un exemple de test de mon e-mail sur Email on Acid.

En conclusion, je dirais que Flexbox dans un e-mail pose malheureusement plus de problèmes qu’il n’aide à en résoudre. Je pense que ça peut être intéressant à utiliser, mais uniquement pour des problèmes qui ne peuvent pas être résolus autrement. Par exemple, la propriété order permet de réordonner les éléments, indifféremment de leur ordre dans le code HTML. iOS 9 va enfin supporter les déclarations @supports en CSS. On pourra alors écrire le code suivant :

@supports(order) {
	.block-to-reorder {
		order:1;
	}
}

De quoi faire un peu d’amélioration progressive, en attendant un meilleur support…

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Créer un e-mail responsive sans media queries

Nicole Merlin a écrit un formidable article récapitulant les bonnes pratiques d’intégration moderne d’un e-mail optimisé pour mobile sans media queries. C’est, à peu de choses près, la façon dont j’intègre également des e-mails : colonnes en display:inline-block, commentaires conditionnels pour Outlook, et media queries pour ajuster la version desktop.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Le webmail mobile d’Orange et les double tirets

J’ai découvert tout récemment qu’il existait une version mobile du webmail d’Orange. Celle-ci semble utiliser le même préfixage de règles CSS que son pendant desktop, avec le même support de propriétés CSS (ce qui est plutôt une bonne nouvelle puisqu’Orange est plutôt permissif de ce côté là).

Cependant, j’ai remarqué un gros problème au niveau de l’interprétation de double tirets dans le code HTML ou CSS. Le webmail mobile d’Orange va systématiquement remplacer toute occurrence de -- (tiret tiret) par - - (tiret espace tiret). Et ça, c’est très pénible, en particulier si comme moi vous appréciez la notation de la méthodologie BEM. Prenons par exemple le code suivant…

<style>
	.button--primary { color:#fff; background:#333; }
</style>
<a class="button--primary" href="http://www.hteumeuleu.fr/">Mon blog</a>

…sera transformé par le webmail mobile d’Orange en…

<style>
	.button- -primary { color:#fff; background:#333; }
</style>
<a class="button- -primary" href="http://www.hteumeuleu.fr/">Mon blog</a>

La règle CSS .button- -primary n’a alors plus aucun sens, et ses styles sont ignorés par le navigateur. La solution est alors de ne jamais utiliser de double tirets dans un nom de classe HTML ou une règle CSS. Soit.

Mais ce problème touche également les commentaires HTML. Ainsi le commentaire suivant…

<!-- Ceci est un commentaire HTML -->

…sera transformé par le webmail mobile d’Orange en…

<!--- - Ceci est un commentaire HTML - --->

Par chance, les balises ouvrantes et fermantes du commentaire HTML sont quand même conservés. Mais ça se gâte si on utilise un commentaire conditionnel, par exemple pour cibler certaines versions d’Outlook. Ainsi le commentaire conditionnel suivant…

<!--[if gte mso 9]>Du contenu visible uniquement sur Outlook.<![endif]-->

…sera transformé par le webmail mobile d’Orange en…

<!--- -[if gte mso 9]-->Du contenu visible uniquement sur Outlook.<!--[endif]- --->

Le commentaire est ici carrément réécrit, avec une fermeture avec le [if gte mso 9], et une réouverture avant le [endif]. Ainsi, le contenu à l’intérieur du commentaire conditionnel, censé s’afficher uniquement sur Outlook, sera visible sur le webmail mobile d’Orange. Je n’ai alors malheureusement pas d’autre solution que de ne pas utiliser de commentaire conditionnel. Ou alors de choisir de ne pas supporter ce webmail mobile.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Les statistiques des webmails en France en mars 2015

Le Journal du Net a publié les statistiques de consultation des webmails en France en mars 2015, telles que mesurées par Médiamétrie (j’en parlais un peu l’an dernier).

  1. Orange (11,89, 25,8%) (12,442 millions, 26,8%)
  2. Gmail (11,24 millions, 24,4%) (au lieu de 3 en 2013, 8,637 millions, 18,6%)
  3. Outlook (8,9 millions, 19,3%) (au lieu de 2 en 2013, 8,966 millions, 19,3%)
  4. SFR (4,29 millions, 9,3%) (5,186 millions, 11,2%)
  5. Yahoo (3,95 millions, 8,6%) (5,185 millions, 11,2%)

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Un e-mail interactif avec filtre SVG et transitions CSS

Cette année, Litmus organise des concours communautaires visant à présenter des concepts d’e-mails un peu plus originaux que de trucs tout en tableaux. Le second concours vient de se terminer, et avait pour but de présenter une navigation créative au sein d’un e-mail. Pour participer, j’ai eu envie de porter cet effet de menu gluant créé par Lucas Bebber (et détaillé chez Codrops).

C’est un exemple particulièrement intéressant car cet effet nécessite à la fois l’utilisation d’un filtre SVG pour l’effet gluant à proprement parler, de transitions et transformations CSS pour faire bouger les éléments, et d’une interaction sans JavaScript. J’ai appris plein de choses en m’essayant à cet exercice. Voici le résultat final de ma participation et quelques détails sur le fonctionnement de tout ça.

Lire la suite de « Un e-mail interactif avec filtre SVG et transitions CSS »

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Yahoo supporte les media queries

C’est la nouvelle de la semaine rapportée par FreshInbox : Yahoo supporte désormais officiellement les media queries. Précédemment, Yahoo filtrait les media queries, et les filtrait mal. Ainsi le code suivant…

@media only screen and (max-width:600px) {
	.box { width:auto; } 
	.box-title { font-size:1.25em; }
}

… était transformé en :

_filtered #yiv6851014585 {
}
	#yiv6851014585 .yiv6851014585box-title { font-size:1.25em; }
}

Yahoo prenait le contenu entre la première accolade ouvrante d’une media query et la première accolade fermante (correspondant à la première règle), et filtrait le tout. Les autres règles contenues dans la media query se trouvait alors appliquée quelque soit le medium. On utilisait alors des sélecteurs d’attributs dans les media queries pour éviter que les règles ne s’appliquent. Tout ça, c’est désormais terminé.

Et cette correction ne vient pas de nulle part. Il y a tout juste un mois, Justin Khoo a remonté le bug sur la plate-forme dédiée de Yahoo. Et en un mois seulement, Yahoo a fait la correction. C’est très encourageant de voir que Yahoo est prêt à faire ce genre de corrections.

L’autre bonne nouvelle, c’est que cette modification s’applique pour toutes les versions de Yahoo, soit le webmail desktop, mais aussi les applications iOS ou Android.

Tout n’est cependant pas tout rose. Yahoo ne supporte que les media queries basées sur min-width, max-width, min-height ou max-height. Les media queries basées sur min-device-width, min-device-height, max-device-width, max-device-height-webkit-min-device-pixel-ratio ou même print seront filtrées.

Ainsi le code suivant…

@media only screen and (max-device-width:600px) {
	.box { width:auto; } 
}

… est transformé en :

@media screen and ( _filtered_a ) {
	#yiv6851014585 .yiv6851014585box { width:auto; } 
}

Un autre bug survient dès que l’on imbrique des media queries les unes dans les autres. Ainsi le code suivant…

@media only screen and (min-width:320px) {
	@media only screen and (max-width:480px) {
		.box { background:#001F3F; }
	}

	.box { background:#FF851B; }
}

… est transformé en :

@media screen and (min-width:320px) {
	@media screen and (max-width:480px)
	#yiv6851014585 .yiv6851014585box { background:#001F3F; }
}

#yiv6851014585 .yiv6851014585box { background:#FF851B; }
#yiv6851014585

Alors très clairement, je n’écris jamais de media queries comme cela (et j’ai du mal à imaginer des cas où ce serait indispensable de l’écrire comme ça). Mais cela pourrait devenir courant avec l’arrivée future de la spécification des Media Queries niveau 4.

Bravo quand même à Yahoo d’avancer dans la bonne direction. J’espère que ceci est le premier pas d’une longue marche.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Le webmail mobile de La Poste et le mot « body »

En refaisant des tests sur le webmail mobile de La Poste, je suis tombé par hasard sur un nouveau bug. Par défaut, le webmail mobile de La Poste remplace la balise <body> d’un e-mail par un <div class="tag_body">. C’est une pratique plutôt courante chez les webmails. Jusqu’ici tout va bien.

Afin d’ajuster les styles appliqués sur la balise <body>, le webmail de La Poste remplace aussi les sélecteurs body { } par div.tag_body { }. Jusqu’ici tout va bien.

Mais si la moindre de vos classes a le malheur de contenir le mot body isolé, alors elle sera également affectée par ce remplacement dans les styles. Ainsi un sélecteur .media-body sera transformé en .media-div.tag_body. Curieusement, cette transformation ne s’applique pas si le terme body est inclus dans un mot.

Ainsi le code suivant…

.body {  }
.media-body {  }
.everybody {  }

… est transformé en :

.wrapper_h8uftw div.tag_body {  }
.wrapper_h8uftw .media-div.tag_body {  }
.wrapper_h8uftw .everybody {  }

Afin d’éviter ce problème, je n’ai pas trouvé d’autre solution que d’éviter d’utiliser toute classe contenant le mot body.