Comment sortir l'intégration d'e-mails de la préhistoire ?

PARIS WEB 16 OCTOBRE 2014

RÉMI PARMENTIER INTÉGRATEUR Il m’arrive d’intégrer des e-mails. Et comme
beaucoup de mes confrères et consoeurs, j’ai envie de m’enfuir. L’intégration d’e-mails ça ressemble un peu à ça.

Un e-mail à intégrer On a un méchant e-mail à
intégrer.

un intégrateur Un intégrateur qui s’enfuit en courant.

un chef de projet Et un chef de projet qui
prie pour que tout se passe bien.

Bienvenue dans le monde de l’intégration d’e-mails. J’ai voulu en
parler parce que c’est un monde qui va mal. Et pourtant on trouve des e-mails dans quasiment chaque projet web.

Que ce soit un e-mail commercial mettant en avant les
dernières nouveautés de votre boutique.

Un e-mail de conﬁrmation de commande.

Une lettre d’information envoyée à vos abonnés tous les mois.

Ou un e-mail de mot de passe oublié pour accéder
à un compte en ligne ou à une administration de site.

Et surtout, personnellement, ÇA M’ÉNERVE de recevoir des e-mails pas
consultables tant que les images ne sont pas chargées.

ÇA M’ÉNERVE de recevoir des e-mails du gouvernement Français qui
ressemblent plus à des spams nigériens.

ÇA M’ÉNERVE de recevoir des e-mails qui parlent de qualité
web et qui ne sont pas agréables à lire sur mobile.

comment sortir de la préhistoire Voici donc quelques réﬂexions personnelles
sur comment sortir l’intégration d’e-mails de la préhistoire.

À la base, l’intégration d’e-mails n’est pas si différente que
sur le web. On va devoir travailler pour différents types d’appareils et différents navigateurs.

Mais en plus, on va devoir travailler pour différents webmails
et applications mail. Ça rend les tests encore plus compliqués. D’autant que certaines applications ont différentes versions…

Par exemple, Outlook 2003 utilise le moteur de rendu d’IE.
Mais d’IE présent lors de l’installation d’Outlook. Si vous installez Outlook 2003 avec IE6 présent, puis que vous mettez à jour IE6 vers IE8, Outlook 2003 sera toujours coincé sur le moteur d’IE6.

Mets ta tête entre les genoux.

Heureusement il y a des outils en ligne pour faciliter
tout ça. Par exemple Litmus. http:/ /www.litmus.com

GetInbox (un service français avec des tests sur les webmails
français). http:/ /www.getinbox.com

Ou Email on Acid. http:/ /www.emailonacid.com

En faisant un test, on obtient une palette de captures
d’écran sur différents webmails, navigateurs, appareils, applications, …

TOUT LE MONDE FAIT N’IMPORTE QUOI Mais quelque chose qu’il
faut bien avoir en tête dans l’intégration d’e- mails, c’est que…

CERTAINS CLIENTS ONT DES CONTRAINTES DATÉES. Par exemple…

pas d’images de fond ! pas de balises h1 !
pas de styles ! On m’impose parfois ce type de contrainte. Mais c’est totalement désuet et faux aujourd’hui. En particulier le dernier point.

ON PEUT UTILISER CSS DANS UN E-MAIL…

Campaign Monitor maintient depuis plusieurs années un guide de ce
qui marche ou ne marche pas en CSS selon les applications et webmails. http:/ /www.campaignmonitor.com/css

ON PEUT UTILISER CSS DANS UN E-MAIL… <h1 style="color:#f60; font:1em
sans-‐serif;"></h1> Donc on peut utiliser CSS directement en ligne sur un élément HTML. (Ça marche bien sur Gmail par exemple.)

ON PEUT UTILISER CSS DANS UN E-MAIL… <style> h2
{ color:#f60; font:1em sans-‐serif; } </style> Ou alors dans une balise <style> dans le <head> d’un e-mail. Ça marche bien sur les autres webmails.

ON PEUT UTILISER CSS DANS UN E-MAIL… <link rel="stylesheet" href="email.css"
/> Ou avec une balise <link>. Ça marche bien sur certaines applications mail.

CSS DANS UN E-MAIL, ÇA DÉPEND… Mais comme souvent en
intégration, CSS dans un e-mail, « ça dépend ».

CSS DANS UN E-MAIL, ÇA DÉPEND… Du moteur de rendu.
Si vous utilisez des propriétés CSS3 mais que vous testez sur le moteur de rendu d’IE6, vos effets ne seront pas pris en compte.

CSS DANS UN E-MAIL, ÇA DÉPEND… Des balises. Mais ça
dépend aussi parfois des balises sur lesquelles vous utilisez des propriétés CSS.

Par exemple, Outlook 2007 utilise le moteur de rendu de
Word. C’est surement bien pour écrire un e-mail, mais c’est horrible pour du rendu HTML.

OUTLOOK 2007/2010/2013 SUPPORT DE CSS DANS CORE <body>, <span> color
font text-align background-color Outlook 2007 a trois niveaux de support de CSS correspondant à certains éléments HTML et certaines propriétés CSS. Le premier niveau, CORE, ne concerne que les balises <body> ou <span>, sur lesquelles on peut uniquement utiliser certaines propriétés comme color, font, …

OUTLOOK 2007/2010/2013 SUPPORT DE CSS DANS CORE COREEXTENDED <body>, <span>
color font text-align background-color <div>, <p> text-indent margin Le deuxième niveau, COREEXTENDED, concerne les balises <div> et <p>, sur lesquelles on peut utiliser les propriétés text-indent et margin, en plus des propriétés du niveau CORE.

FULL OUTLOOK 2007/2010/2013 SUPPORT DE CSS DANS CORE COREEXTENDED <body>,
<span> color font text-align background-color <div>, <p> text-indent margin <table>, <td>, <h1>, <ul>, … width height padding border-left Le dernier niveau, FULL, concerne les autres balises supportées sur lesquelles on peut utiliser les propriétés width, height, …, en plus des propriétés des autres niveaux.

FULL OUTLOOK 2007/2010/2013 SUPPORT DE CSS DANS CORE COREEXTENDED <body>,
<span> color font text-align background-color <div>, <p> text-indent margin <table>, <td>, <h1>, <ul>, … width height padding border-left Ça signiﬁe que sur Outlook 2007 /2010/2013, on peut utiliser la propriété padding sur un <td>, mais pas sur un <div>. Ce qui nous pousse à principalement utiliser des tableaux.

- Je hais les ordinateurs. - C’est réciproque.

CSS DANS UN E-MAIL, ÇA DÉPEND… Des webmails.

CERTAINS WEBMAILS ONT DES STYLES TROP GÉNÉRIQUES.

Balise <h2> Par exemple, sur le webmail mobile d’Outlook.com, si
j’utilise une balise <h2> sans aucun style, je vois qu’elle hérite déjà de certains styles.

Balise <h2> Si j’inspecte le code, je vois qu’effectivement, il
y a des règles génériques sur la balise <h2> avec des propriétés background- color, border-bottom.

<h2 style="white-‐space:normal; background:none; border:none;"> Bonjour Paris Web </h2>
Ça signiﬁe que si je veux utiliser une balise <h2>, il faudra à chaque fois que je surcharge ces propriétés. En étant habitué à faire du web, vous aurez tendance à regarder le code d’un e- mail et à vous dire…

C’est vraiment un gros tas de merde.

CERTAINS WEBMAILS PRÉFIXENT LES CSS. Le préﬁxage des styles est
plutôt une bonne idée de la part des webmails pour éviter qu’un intégrateur mal intentionné ne vienne surcharger des styles propres au webmail.

C’est ce que font les webmails français comme ceux d’Orange,
SFR, La Poste, ou Voila, qui utilisent tous le même moteur de webmail et de préﬁxage de styles.

.box { width:600px; } Si on prend une règle
CSS basique comme celle-ci…

#message .box { width:600px; } … elle sera alors
préﬁxée comme ça. L’identiﬁant «message» se trouve alors plus haut dans le code HTML. Tout fonctionne correctement.

.box { width:600px; } @media only screen and (max-‐width:600px)
{ .box { width:auto; } .box-‐title { font-‐size:1.25em; } } Ça se complique avec des media queries.

#message .box { width:600px; } @media only screen and
(max-‐width:600px) { .box { width:auto; } #message .box-‐title { font-‐size:1.25em; } } Ici les règles sont bien préﬁxées, SAUF la première règle à l’intérieur d’une media query.

(max-‐width:600px) { .box { width:auto; } #message .box-‐title { font-‐size:1.25em; } } + spécifique Pas préfixé Mais du coup ça signifie la première règle est plus spécifique (id + classe > classe). Du coup, les propriétés surchargées dans la media query ne seront pas prises en compte.

(max-‐width:600px) { .box { width:auto !important; } #message .box-‐title { font-‐size:1.25em; } } + spéciﬁque Pour éviter ça, on doit sortir le bazooka CSS : !important.

La version mobile du webmail de La Poste préﬁxe aussi
les règles CSS, mais avec quelques bugs supplémentaires.

{ .box { width:auto; } .box-‐title { font-‐size:1.25em; } } Si on reprend le même exemple…

.wrapper_pw161014 .box { width:600px; } @media only screen and
(max-‐width:600px) { .box { width:auto; } .wrapper_pw161014 .box-‐title { font-‐size:1.25em; } Les règles sont bien préﬁxées, cette fois-ci par une classe. Il y a toujours le même bug concernant la première règle à l’intérieur d’une media query.

.wrapper_pw161014 .box { width:600px; } .wrapper_pw161014 @media only screen
and (max-‐width:600px) { .box { width:auto; } .wrapper_pw161014 .box-‐title { font-‐size:1.25em; } } Mais en plus, le webmail mobile de La Poste préﬁxe la première media query qu’il trouve. Du coup, tout le code qui suit n’a plus de sens en CSS, et est ignoré.

.box { width:600px; } @media only screen and (max-‐width:0)
{ body { margin:0; } } @media only screen and (max-‐width:600px) { .box { width:auto; } .box-‐title { font-‐size:1.25em; } } Pour éviter ça, on peut rajouter une media query complétement bidon en premier dans notre code.

.wrapper_pw161014 .box { width:600px; } .wrapper_pw161014 @media only screen
and (max-‐width:0) { body { margin:0; } } @media only screen and (max-‐width:600px) { .box { width:auto; } .wrapper_pw161014 .box-‐title { font-‐size:1.25em; } Ainsi, c’est elle qui se trouve préﬁxée (et ignorée), mais les media queries suivantes seront bien prises en compte.

Outlook.com aussi préﬁxe les styles. Et ils font ça vraiment
bien.

{ .box { width:auto; } .box-‐title { font-‐size:1.25em; } } En reprenant toujours le même exemple…

.ExternalClass .ecxbox { width:600px; } @media only screen and
(max-‐width:600px) { .ExternalClass .ecxbox { width:auto; } .ExternalClass .ecxbox-‐title { font-‐size:1.25em; } } Les styles sont bien préﬁxés par une classe «ExternalClass», et les classes renommés avec un préﬁxe «ecx». La classe «ExternalClass» est bien présente plus haut dans le HTML, et tout fonctionne bien.

Microsoft a utilisé le même préﬁxage pour la version mobile
du webmail d’Outlook.com. Sauf que, si on inspecte le code…

.ExternalClass ? ✖ La classe ExternalClass ne se trouve nulle
part dans le HTML. Du coup, tous les styles présent dans une balise <style> seront ignorés par Outlook.com sur mobile.

Je ne supporte pas ces conneries d’informaticien. Meeeerde !

QUIZ Comment s’appelle le responsable d’Outlook.com chez Microsoft ? A.
Bryan D. Gueulasse B. Jason Abject C. Jeff Ed Lamherd D. Richard Craddock Trop bien, un quiz !

Bon, ok, les blagues sur les noms de famille c’est
un peu facile. Par exemple moi je m’appelle Parmentier, et on n’en fait pas tout un plat.

CERTAINS WEBMAILS SUPPRIMENT VOTRE CODE. Pour éviter qu’on utilise des
propriétés «dangereuses», comme «position», ou alors des media queries…

Par exemple, Yahoo.com ne supporte pas les media queries. Elles
seront donc ﬁltrées si vous en avez dans votre code.

{ .box { width:auto; } .box-‐title { font-‐size:1.25em; } } On reprend toujours le même exemple…

#yiv6851014585 .yiv6851014585box { width:600px; } @media only screen and
(max-‐width:600px) { #yiv6851014585 .yiv6851014585box { width:auto; } #yiv6851014585 .yiv6851014585box-‐title { font-‐size:1.25em; } } Yahoo.com va d’abord préﬁxer les règles CSS, comme les autres webmails.

(max-‐width:600px) { #yiv6851014585 .yiv6851014585box { width:auto; } #yiv6851014585 .yiv6851014585box-‐title { font-‐size:1.25em; } } Et ensuite, pour ﬁltrer une media query, ils vont chercher ce qui se trouve entre la première accolade ouvrante et la première accolade fermante.

#yiv6851014585 .yiv6851014585box { width:600px; } _filtered #yiv6851014585 { }
#yiv6851014585 .yiv6851014585box-‐title { font-‐size:1.25em; } } Et ils vont ﬁltrer tout ça.

#yiv6851014585 .yiv6851014585box-‐title { font-‐size:1.25em; } } Sauf que du coup la deuxième règle qui se trouvait dans ma media query s’en trouve sortie, et donc appliquée quelque soit le media.

{ *[class="box"] { width:auto; } *[class="box-‐title"] { font-‐size:1.25em; } } Pour éviter ça, des petits malins ont repéré que Yahoo.com ﬁltrait aussi les règles basées sur des sélecteurs d’attributs. Donc si on les utilise pour les règles dans une media query…

(max-‐width:600px) { *[class="box"] { width:auto; } *[class="box-‐title"] { font-‐size:1.25em; } } Yahoo.com va bien préﬁxer les règles supportées.

(max-‐width:600px) { #yiv6851014585 * .filtered99999 { width:auto; } #yiv6851014585 * .filtered99999 { font-‐size:1.25em; } } Puis il va ﬁltrer les règles non supportées en les remplaçant par un sélecteur bidon.

#yiv6851014585 * .filtered99999 { font-‐size:1.25em; } } Puis il va ﬁltrer les media queries. Les autres règles à l’intérieur de la media query s’en trouvent toujours sorties, mais comme elles sont ﬁltrées, elles ne s’appliquent plus. C’est souvent grâce à ce genre de bidouille qu’on va pouvoir s’en sortir en intégrant un e-mail.

Petite futée.

Outlook.com aussi ﬁltre certaines propriétés CSS.

margin Par exemple, Outlook.com va toujours ﬁltrer la propriété margin
(même dans un attribut style sur une balise).

Margin Mais pas la propriété Margin.

mArgin Ou mArgin.

maRgin Ou maRgin.

marGin Ou marGin. En gros, on peut très bien utiliser
la propriété margin sur Outlook.com, tant qu’on ne l’écrit pas tout en minuscule.

J’ai vomi.

CERTAINS WEBMAILS RETOUCHENT VOS IMAGES. C’est le cas de Gmail
par exemple, qui pour afﬁcher les images automatiquement dans un e-mail, les héberge sur leurs serveurs, et les recompresse au passage.

On constate une recompression un peu forte en JPG, et
complétement déformée en GIF. Du coup il vaut mieux utiliser du PNG quand c’est possible.

Mais certaines vieilles applications, comme Lotus Notes 6 ou 7,
ne supportent pas le format PNG.

LES WEBMAILS UTILISENT DIFFÉRENTS DOCTYPE. Ensuite, différents webmails utilisent différents
doctype.

HTML 5 YAHOO, GMAIL, OUTLOOK.COM, ORANGE, LA POSTE MOBILE HTML
4 TRANSITIONAL LA POSTE, SFR, FREE PAS DE DOCTYPE SPARROW (iOS) Le plus courant est le doctype HTML5. Mais on retrouve un peu de HTML4. Et parfois le doctype sera supprimé.

Pas de doctype Ça peut être génant parce qu’on peut
avoir des différences de rendu selon le doctype. Un e-mail sans doctype…

Doctype HTML5 … peut s’afﬁcher différemment avec un doctype HTML5
car la spéciﬁcation gère différemment les images, et un espace blanc peut apparaître alors sous chaque image.

<img src="rex.jpg" alt="" style="display:block;" /> Pour éviter ça, on
peut ajouter un display:block sur chaque image.

<div style="font-‐size:0;"> <img src="rex.jpg" alt=""/> </div> Ou ajouter un
élément parent de type block avec un font-size:0;

Je préconise plutôt d’utiliser le doctype HTML5. Mais dans l’application
Mail de Firefox OS…

<!doctype html> … le doctype sera afﬁché en haut du
mail si on l’écrit en minuscules.

TOUT PEUT CHANGER DU JOUR AU LENDEMAIN. Et le plus
dur dans tout ça, c’est que…

Par exemple, l’application Mailbox sur iOS 8, dans une récente
mise à jour, a un bug où l’e- mail au chargement va petit à petit rétrécir, sans raison. Alors en général dans le web, quand on est confronté à ce genre de spéciﬁcités, on va regarder les stats et voir si tel navigateur est encore beaucoup utilisé.

Litmus diffuse des statistiques mensuelles des applications et webmails les
plus utilisés. Sauf que pour avoir ces chiffres, ils se basent sur l’afﬁchage d’une image de tracking à l’intérieur du mail. Du coup, ça avantage forcément toutes les applications qui afﬁchent les images par défaut.

Novembre 2013 3,02 % C’est le cas notamment de Gmail.
En novembre 2013, Litmus estimait que Gmail avait 3,02% de parts de marché. Gmail bloquait alors les images par défaut.

Décembre 2013 Afﬁchage des images par défaut En décembre 2013,
Gmail a commencé a afﬁcher les images par défaut.

Janvier 2014 9,05 % Le mois suivant, ils se sont
retrouvés à 9,05% de parts de marché.

Septembre 2014 15 % Le mois dernier, après avoir continuer
à afﬁcher les images par défaut dans leurs applications mobiles, Gmail était estimé à 15% de parts de marché.

* Données basées sur 1,8 milliards d’ouvertures de près de
22 milliards de destinataires d’e-mails. Campaign Monitor afﬁche ﬁèrement que 41% des e-mails reçus depuis leurs serveurs l’an dernier était ouvert sur mobile. Mais si on regarde la petite ligne en bas, on peut lire…

* Données basées sur 1,8 milliards d’ouvertures de 22 milliards
d’e-mails reçus. Ça signiﬁe que pour 20,2 milliards d’e-mails, on ne sait pas où ils ont été ouverts. Peut- être qu’ils ont été lus avec les images désactivées sur desktop.

En réalité, les chiffres de Campaign Monitor ressemblent plus à
ça…

Ça signiﬁe que le rendu d’un e- mail sans images
est super important.

<img src="rex.jpg" alt="" style="display:block; background:#000;
color:#fff; font:16px sans-‐serif;" /> Pour moi, il faut toujours prévoir au minimum : - une couleur de fond - une police, couleur et taille de texte

Ça permet de faire des trucs rigolos, comme ici dans
un e- mail envoyé par Nintendo Australia pour un jeu LEGO.

Ou ici dans un e-mail envoyé par Sony pour un
jeu Transformers.

L’OPTIMISATION POUR MOBILES Alors même si on n’a pas de
chiffres ﬁables pour se convaincre d’optimiser ses e-mails pour mobile, c’est dans la continuité de l’expérience utilisateur. Si je peux commander sur mobile, c’est normal que l’e-mail de conﬁrmation que je reçoive soit optimisé pour ce support.

1. Texte brut Une première approche c’est de faire du
text brut. Ça veut dire pas de mise en forme, pas d’images, pas de liens. Mais ça marche partout, optimisé pour toute taille d’écran, peu importe la déﬁnition.

2. MOBILE FRIENDLY Un autre approche consiste à faire ce
que certains appellent du «Mobile friendly», ou encore…

2. MOBILE AWARE Badumtss

Par exemple, cet e-mail chez Threadless n’a aucune optimisation technique
particulière.

Mais simplement en étant redimensionné automatiquement à la taille de
l’écran sur iPhone, j’arrive à bien lire les principaux titres, à comprendre de quoi ça parle.

Malheureusement certaines applications, comme l’application Mail par défaut d’Android, ne
redimensionnent pas l’e-mail, et on se retrouve à devoir faire déﬁler le contenu horizontalement et verticalement.

3. RESPONSIVE Vient alors l’approche responsive.

VIEWPORT ✖ La première chose à faire sur un site
pour faire du responsive est de déﬁnir la meta viewport. Et bien pas pour un e-mail. Soit ça n’est pas utile, soit ça n’est pas pris en compte, ou alors ça peut poser de gros problèmes.

Par exemple, sur Blackberry 5, un e-mail avec une meta
viewport ne s’afﬁchera pas.

L’application mail de Windows Phone 8.1 utilise le moteur de
rendu d’IE7 . Du coup la meta viewport ne sert à rien.

Mais on peut quand même arriver à forcer un afﬁchage
optimisé pour mobile.

3. RESPONSIVE MAIS PAS TROP EN FAIT Chose curieuse dans
le monde de l’intégration d’e-mails, c’est qu’il y a pas mal de monde qui font ce que j’appelle du responsive mais pas trop en fait.

Desktop Mobile C’est à dire qu’ils vont intégrer une version
desktop, une version mobile, et afﬁcher l’une ou l’autre selon la résolution.

C’est ce que fait Apple par exemple. C’est bien parce
que graphiquement ça n’impose aucune contrainte. Mais c’est terrible parce que ça veut dire qu’on envoie à tout le monde deux intégrations.

Certaines vieilles applications Mail (comme Lotus Notes 6 et 7)
ne supportent pas cette méthode, et du coup on se retrouve avec les deux e-mails afﬁchés l’un en dessous de l’autre.

On risque aussi de se heurter à des limitations comme
ici sur iOS où seuls les x premiers Ko de l’e-mail sont téléchargés. La version desktop est donc téléchargée, mais comme elle est masquée en CSS, rien ne s’afﬁche à l’écran.

3. RESPONSIVE AVEC DES TABLEAUX Par contre on peut faire
des trucs pratiques avec des tableaux en responsive.

A B C Par exemple, si on a un tableau
d’une ligne avec trois cellules A, B et C…

A B C On peut les passer les unes en
dessous des autres.

<table cellspacing="20"> <tr> <td>A</td> <td>B</td>
<td>C</td> </tr> </table> Pour faire ça, il nous faut un tableau.

@media only screen and (max-‐width:600px) { td {
display:block; Margin-‐bottom:20px; } } Et ensuite, dans une media query, on va passer nos cellules en display:block.

C B A On peut aussi inverser l’ordre des cellules.
Par exemple si on veut cet ordre sur la version desktop…

<table cellspacing="20" dir="rtl"> <tr> <td>A</td>
<td>B</td> <td>C</td> </tr> </table> On va jouer avec l’attribut «dir=rtl». L’attribut sera bien respecté sur desktop, mais ignoré sur mobile puisqu’on passe les cellules en display:block.

Problème : sur WebKit sur une page sans doctype, tout
ça ne fonctionne plus. (Comme ici sur Sparrow sous iOS, ou sur Android Mail 4.4)

A B Alors plutôt que de jouer avec des cellules,
on peut jouer avec des tableaux. Par exemple ici, on a deux tableaux ﬂottants A et B.

A B Sur mobile on pourra obtenir ce rendu.

<table width="50%" style="min-‐width:290px;" align="left"> <tr> <td>A</td>
</tr> </table> <table width="50%" style="min-‐width:290px;" align="right"> <tr> <td>B</td> </tr> </table> Pour ça, il faut jouer avec l’attribut align, et préciser un «min-width» sur le tableau.

A B Problème : sur des résolutions intermédiaires, le rendu
n’est pas top.

En CSS2.1, l’effet de ‘min-width’ et ‘max-width’ sur des tableaux
est indéfini. Et surtout : les propriétés min- width et max-width ne s’appliquent pas sur des tableaux sur d’anciens WebKit.

En CSS2.1, l’effet de ‘min-width’ et ‘max-width’ sur des tableaux
est indéfini. C’est dans la spec ! Merci la spec !

Alors comment optimiser des e-mails pour mobile ? Ne peut-on
pas s’inspirer de tout ce qu’on a appris sur le web ces dix dernières années ?

SÉMANTIQUE N’a-t-on pas appris des notions de…

DÉGRADATION GRACIEUSE Ou des principes de…

AMÉLIORATION PROGRESSIVE Ou encore d’…

EST-CE QU’UNE PAGE WEB DOIT AVOIR LE MÊME RENDU PARTOUT
? Et surtout, on a appris à répondre à certaines questions. Par exemple :

EST-CE QU’UN E-MAIL DOIT AVOIR LE MÊME RENDU PARTOUT ?
Alors…

Récemment j’ai eu à intégrer un e- mail avec une
présentation comme celle-ci. Un texte HTML avec un effet «comme dans la presse» placé sur une image.

<img> <h1> J’ai commencé par déﬁnir mes éléments en HTML.

position:relative; J’ai ajouté un «position:relative» sur un <div> parent.

position:absolute; left:15px; bottom:15px; Ensuite j’ai positionné le texte par dessus
l’image.

box-‐shadow:-‐4px 0 0 4px #e8a433,
4px 0 0 4px #e8a433; box-‐decoration-‐break:clone; Et puis j’ai rajouté l’effet «comme dans la presse».

On n’obtient clairement pas le même rendu partout.

On aura le rendu souhaité sur les applications qui supportent
bien toutes les propriétés utilisées, comme Apple Mail.

On aura un rendu sans support de box- shadow, mais
avec support de position.

Un rendu sans le support de position, et sans le
support de box-shadow.

Ou encore un rendu sans le support de position, mais
avec le support de box- shadow.

Et ce sera la même chose pour mobile. Ici on
supporte bien les media queries et position, mais pas box-shadow.

Et ici on supporte bien position, mais pas box-shadow ni
les media queries.

A B C On peut alors commencer à se dispenser
de tableaux pour faire de la mise en page. Par exemple ici on a trois div A, B et C.

C A B On va pouvoir les réagencer de manière
ﬂuide en s’assurant qu’elles restent centrées.

A B C Pour avoir un rendu comme ça sur
mobile.

<div> <div style="display:inline-‐block; width:290px;"> A </div>
<div style="display:inline-‐block; width:290px;"> B </div> <div style="display:inline-‐block; width:290px;"> C </div> </div> Pour ça, on va jouer avec la propriété display:inline-block.

<div style="text-‐align:center; font-‐size:0;"> <div style="display:inline-‐block; width:290px;"> A
</div> <div style="display:inline-‐block; width:290px;"> B </div> <div style="display:inline-‐block; width:290px;"> C </div> </div> Sur un <div> parent, on va ajouter un text-align:center (qui va centrer les trois blocs) et font- size:0 (qui évite des marges entre les blocs).

<!-‐-‐[if mso]> <table …> <tr>
<td> <![endif]—> <div style="display:inline-‐block; width:290px;"> A </div> <!-‐-‐[if mso]> </td> </tr> </table> <![endif]-‐-‐> Outlook ne supporte pas display:inline-block. Pour avoir une mise en page améliorée, on peut utiliser des commentaires conditionnels.

<div style="text-‐align:center; font-‐size:0;"> <!-‐-‐[if mso]> <table …><tr><td> <![endif]-‐-‐>
<div style="display:inline-‐block; width:290px;"> A </div> <!-‐-‐[if mso]> </td><td> <![endif]-‐-‐> <div style="display:inline-‐block; width:290px;"> B </div> <!-‐-‐[if mso]> </td><td> <![endif]-‐-‐> <div style="display:inline-‐block; width:290px;"> C </div> <!-‐-‐[if mso]> </td></tr></table> <![endif]-‐-‐> </div> Ça donne tout ce code au ﬁnal. Ça permet d’allier une optimisation mobile poussée (qui ne repose pas sur des media queries), et le support d’Outlook et le moteur de Word.

Et certains n’hésitent pas à tester des effets encore plus
poussés. Par exemple, Litmus utilisent des animations CSS dans leurs e- mails.

Ils ont aussi fait un e-mail avec une vidéo dans
le header. Ça ne marchait que sur Apple Mail, mais avec un rendu statique pour les autres applications et webmails.

La marque B&Q fait carrément des e-mails interactifs avec des
carousels. Encore une fois, ça ne fonctionne pas partout, mais ça afﬁchera un contenu statique ailleurs.

L’INTÉGRATION D’E-MAILS, C’EST COMPLIQUÉ. En résumé, c’est compliqué. Et ce
qui me fait peur, c’est que ça ne bouge pas beaucoup.

En 2007 s’est tenue à Paris une réunion de travail
du W3C sur les e-mails HTML. Et il s’est dit a peu près ce que je raconte aujourd’hui. Ça signiﬁe que rien n’a vraiment changé depuis 2007 .

Campaign Monitor avait lancé un projet de standardisation, mais pas
très ambitieux (ils voulaient uniquement le support de quelques propriétés CSS), et surtout ça ne visait que des webmails ou applications américains.

En 2014, un groupe communautaire a été lancé au sein
du W3C. Ça avait bien démarré, mais il n’y a eu quasiment aucun message depuis. Et certains venaient uniquement pour réclamer le support de MathML (qui, j’en suis sûr est très utile, mais on est tellement loin de ça aujourd’hui).

Cette année j’ai ouvert un blog pour commencer à parler
de tout ça. Mais ce n’est pas en étant tout seul que je vais arriver à faire bouger les choses…

ET SI ON ARRÊTAIT DE FAIRE N’IMPORTE QUOI ? Développeurs
d’applications mail ou de webmails : arrêtez de préﬁxer des styles n’importe comment, arrêter d’utiliser des moteurs supportant mal CSS. Intégrateurs : arrêtez de ne faire que des tableaux. Sortez de votre zone de confort. Faites des tests. Expérimentez. En 7 ans, quasiment rien n’a changé. J’espère que dans 7 ans, les choses auront changé.

J’espère que dans 7 ans, on pourra regarder dans le
rétroviseur, et se dire que ce méchant e-mail à intégrer…

…n’est ﬁnalement pas si terriﬁant.

Et que l’intégration d’e-mails soit un jeu d’enfant.

Rémi @HTeuMeuLeu [email protected] http://www.hteumeuleu.fr merci

Comment sortir l'intégration d'e-mails de la pr...

Comment sortir l'intégration d'e-mails de la préhistoire ?

More Decks by HTeuMeuLeu

Other Decks in Technology

Featured

Transcript