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

Résoudre les problèmes de mode sombre de Gmail avec les modes de fusion en CSS

Depuis ses débuts en octobre 2019, le mode sombre (« dark mode ») de Gmail cause pas mal d’arrachage de cheveux. Les choses se sont améliorées et uniformisées au fil du temps, mais il reste encore des différences majeures entre le mode sombre de Gmail sur iOS contre celui sur Android.

Un des plus gros problèmes sur iOS est que Gmail insiste pour changer n’importe quelle couleur de texte clair en une couleur de texte sombre. Donc un email déjà sombre avec du texte blanc sur un fond noir sera transformé en texte noir sur fond blanc. Non seulement ça me semble un peu contre productif, mais ça créé aussi de vrais problèmes de lisibilité et d’accessibilité.

Voici par exemple un email de Nest.

Ça fait un moment que je réfléchis à comment on pourrait résoudre ça. Et les modes de fusion en CSS (Blend Modes) me sont restés en tête depuis qu’ils sont supportés dans Gmail. Voici donc comment résoudre certains problèmes du mode sombre de Gmail avec des modes de fusion en CSS.

1. Le code de base

Pour cet exemple, on va commencer en utilisant une seule <div> avec un fond noir et un texte blanc.

<div style="background:#000; color:#fff;">
    Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
</div>

2. Comment Gmail transforme les couleurs

Si vous ouvrez un email avec le code ci-dessus dans Gmail sur iOS en mode sombre, vous verrez que les couleurs auront changé. Je n’ai jamais vraiment compris comment Gmail fait pour modifier les couleurs. (On garde toujours notre code d’origine si on copie/colle l’email ou si on le transfère.) Mais le résultat final est similaire à ce que donnerait le code suivant.

<div style="background:#fff; color:#000;">
    Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
</div>

3. Ajout des modes de fusion

Revenons à notre code initial et commençons à faire de la magie avec les modes de fusion. On va ajouter deux <div> internes à notre code, chacune avec un fond noir et un mode de fusion différent.

<div style="background:#000; color:#fff;">
    <div style="background:#000; mix-blend-mode:screen;">
        <div style="background:#000; mix-blend-mode:difference;">
            Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
        </div>
    </div>
</div>

Et pour notre tour final, on va utiliser une image de fond créée par un dégradé linear-gradient en CSS pour maintenir notre couleur de fond souhaitée. (J’ai appris cette technique grâce à Annett Forcier pendant sa présentation sur le mode sombre avec Anne Tomlin l’an dernier.)

<div style="background:#000; background-image:linear-gradient(#000,#000); color:#fff;">
    <div style="background:#000; mix-blend-mode:screen;">
        <div style="background:#000; mix-blend-mode:difference;">
            Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
        </div>
    </div>
</div>

Regardons petit à petit comment ce code est interprété dans Gmail iOS et pourquoi ça fonctionne.

3.1 Comment Gmail transforme ce code

Premièrement, Gmail va changer les couleurs. Le texte blanc va devenir noir, et les fonds noirs vont devenir blancs, à l’exception du dégradé linear-gradient. Notre code finira donc par ressembler à ça.

<div style="background:#fff; background-image:linear-gradient(#000,#000); color:#000;">
    <div style="background:#fff; mix-blend-mode:screen;">
        <div style="background:#fff; mix-blend-mode:difference;">
            Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
        </div>
    </div>
</div>

3.2 Les modes de fusion

Parlons maintenant des modes de fusion. Si on prend la définition de MDN :

Un mode de fusion est une méthode de calcul permettant de déterminer la couleur finale d’un pixel lorsque plusieurs couches sont empilées.

Une opération de fusion nécessite une « couleur source » et la fusionne avec une « couleur d’arrière plan ». Le résultat exact dépend du type de mode de fusion qu’on utilise.

On peut utiliser des modes de fusion dans Photoshop. Et on peut utiliser des modes de fusion en CSS grâce à deux propriétés : background-blend-mode et mix-blend-mode. Les deux ont le même support dans Gmail. Mais comme notre objectif ici est de maintenir la couleur d’un texte, on va utiliser uniquement la propriété mix-blend-mode.

Can I email… mix-blend-mode

Si vous voulez en savoir plus sur les modes de fusion en CSS, je vous recommande très chaudement les articles suivants (en anglais) :

3.3 La première fusion : difference

La première fusion qui a lieu dans notre code est une difference. D’après la définition de la spécification du W3C, une fusion par différence « soustrait la plus sombre des deux couleurs de la couleur la plus claire ». Mathématiquement, le résultat est la valeur absolue de la différence entre notre couleur source (Cs) et notre couleur d’arrière-plan (Cb).

B(Cb, Cs) = |Cb - Cs|

Si on revient à notre code, ce mode de fusion va se passer entre notre texte noir sur fond blanc (suite à la transformation de Gmail) et son parent avec un fond blanc.

<div style="background:#fff;">
    <div style="background:#fff; mix-blend-mode:difference;">
        Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
    </div>
</div>

Mathématiquement, ça signifie que notre texte noir de la source devient…

|Cb - Cs| = |rgb(255,255,255) - rgb(0,0,0)|
          = rgb(255,255,255)

… blanc ! Et le fond blanc de cette source fusionné avec le fond blanc de l’arrière-plan devient…

|Cb - Cs| = |rgb(255,255,255) - rgb(255,255,255)|
          = rgb(0,0,0)

… noir !

Parfait ! Mais attendez, que se passe-t-il si on applique ça dans Gmail en mode clair ? Notre code de base serait comme le suivant.

<div style="background:#000;">
    <div style="background:#000; color:#fff; mix-blend-mode:difference;">
        Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
    </div>
</div>

Notre texte blanc de la source fusionné avec l’arrière-plan noir devient…

|Cb - Cs| = |rgb(0,0,0) - rgb(255,255,255)|
          = rgb(255,255,255)

… blanc ! Et notre fond noir en source fusionné avec le fond noir de l’arrière-plan devient…

|Cb - Cs| = |rgb(0,0,0) - rgb(0,0,0)|
          = rgb(0,0,0)

… noir ! Ça fonctionne toujours !

Mais attendez, on n’aurait pas fini là ? Si vous avez seulement besoin d’un texte blanc sur un fond noir, alors vous pouvez en effet vous arrêter ici. Mais si vous avez besoin d’un texte blanc sur un fond coloré, on va avoir besoin de ce deuxième mode de fusion.

3.4 La deuxième fusion : screen

Revenons un peu en arrière et recommençons avec un texte blanc sur un fond violet (#639).

<div style="background:#639; background-image:linear-gradient(#639,#639); color:#fff;">
    <div style="background:#000; mix-blend-mode:screen;">
        <div style="background:#000; mix-blend-mode:difference;">
            Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
        </div>
    </div>
</div>

Premièrement, Gmail va modifier ces couleurs. Le noir devient blanc, le blanc devient noir, et le violet devient légèrement plus clair.

<div style="background:#c7a4ef; background-image:linear-gradient(#639,#639); color:#000;">
    <div style="background:#fff; mix-blend-mode:screen;">
        <div style="background:#fff; mix-blend-mode:difference;">
            Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
        </div>
    </div>
</div>

Ensuite, la première fusion (difference) s’applique. Mais à ce stade, on obtient exactement le même résultat qu’avant : un texte blanc sur fond noir.

Entre alors en scène notre deuxième fusion : screen. D’après la définition de la spécification du W3C, un mode de fusion screen « multiplie le complément des valeurs de l’arrière-plan et de la couleur source, puis complémente le résultat ». Oui, alors, moi aussi j’ai rien compris. Mais les formules de maths m’ont aidé à comprendre.

B(Cb, Cs) = 1 - [(1 - Cb) * (1 - Cs)]
          = Cb + Cs - (Cb * Cs)

Voyons voir ce qui se passe. À ce stade, c’est comme si on faisait une fusion d’un texte blanc sur un fond noir avec notre arrière-plan violet.

<div style="background:#639;">
    <div style="background:#000; color:#fff; mix-blend-mode:screen;">
        <div>
            Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
        </div>
    </div>
</div>

Notre texte blanc en source (Cs) fusionné avec le fond violet (Cb) devient…

B(Cb, Cs) = Cb + Cs - (Cb * Cs)
          = rgb(102, 51, 153) + rgb(255,255,255) - (rgb(102, 51, 153) * rgb(255,255,255))
          = rgb(102, 51, 153) + rgb(255,255,255) - rgb(102, 51, 153)
          = rgb(255,255,255)

… blanc ! Et notre fond noir en source (Cs) fusionné avec l’arrière-plan violet (Cb) devient…

B(Cb, Cs) = Cb + Cs - (Cb * Cs)
          = rgb(102, 51, 153) + rgb(0,0,0) - (rgb(102, 51, 153) * rgb(0,0,0))
          = rgb(102, 51, 153) + rgb(0,0,0) - rgb(0,0,0)
          = rgb(102, 51, 153)

… violet ! Et voilà, c’est comme ça qu’on maintient un texte blanc sur un fond de n’importe quel couleur. Et ça fonctionne aussi avec des images de fond.

<div style="background:#6db6b0; background-image:url(https://i.imgur.com/F7S1NGq.jpg); background-size:cover; color:#fff;">
    <div style="background:#000; mix-blend-mode:screen;">
        <div style="background:#000; mix-blend-mode:difference;">
            Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
        </div>
    </div>
</div>

Le seul problème ici est que ce code s’applique sur n’importe quel client mail. Et pour ceux qui ne supportent pas mix-blend-mode, seul un fond noir s’affiche. On doit donc faire en sorte que ce code ne s’applique que sur Gmail.

4. Cibler Gmail

La méthode pour cibler Gmail est bien connue depuis plusieurs années (et est même référencée sur HowToTarget.email). Il y a deux pré-requis pour que ça fonctionne :

  1. Avoir un doctype au début de votre code HTML (par exemple : <!DOCTYPE html>)
  2. Ajouter une classe dédiée sur l’élément <body> (par exemple : <body class="body">)

Ensuite on peut cibler n’importe quelle classe dans notre code (par exemple : .foo) avec le sélecteur suivant :

u + .body .foo { }

La raison pour laquelle cela fonctionne est parce que Gmail remplace le doctype d’un email avec un élément <u></u>. Donc le code de base d’un email ci-dessous…

<!DOCTYPE html>
<html lang="en">
<head>
    <title>An HTML email</title>
    <style>u + .body .text { color:green; }</style>
</head>
<body class="body">
    <p class="text">ELO world!</p>
</body>
</html>

… devient :

<div id=":8p" class="a3s aiL msg4142466614215349360">
    <u></u>
    <div class="m_4142466614215349360body">
        <p class="m_4142466614215349360text">
            ELO world!
        </p>
    </div>
</div>

Et le sélecteur CSS utilisé est bien correctement préfixé par Gmail en :

.msg6240499631687324626 u+.m_6240499631687324626body .m_6240499631687324626text { color:green }

Donc, si on revient à notre code, on va déplacer les deux modes de fusion et les styles de background en ligne dans une balise <style> dédiée. (Et on s’assurera bien d’avoir un doctype et une classe .body.)

<style>
    u + .body .gmail-blend-screen { background:#000; mix-blend-mode:screen; }
    u + .body .gmail-blend-difference { background:#000; mix-blend-mode:difference; }
</style>
<div style="background:#639; background-image:linear-gradient(#639,#639); color:#fff;">
    <div class="gmail-blend-screen">
        <div class="gmail-blend-difference">
            Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
        </div>
    </div>
</div>

Un effet de bord imprévu mais bienvenu quand même de cette séparation des styles de mode de fusion est que le code va gracieusement se dégrader dans les applications Gmail avec des comptes non Google. Dans GANGA (comme les emailgeeks aiment bien dire), mix-blend-mode n’est pas supporté. Mais les éléments <style> non plus. Dans ce cas, Gmail appliquera alors simplement ses ajustements de couleurs.

5. Le code final

Voici un exemple complet de code avec tout ce qu’il faut bien en place.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Fixing Gmail’s dark mode issues with CSS Blend Modes</title>
    <style>
        u + .body .gmail-blend-screen { background:#000; mix-blend-mode:screen; }
        u + .body .gmail-blend-difference { background:#000; mix-blend-mode:difference; }
    </style>
</head>
<body class="body">
    <div style="background:#639; background-image:linear-gradient(#639,#639); color:#fff;">
        <div class="gmail-blend-screen">
            <div class="gmail-blend-difference">
                <!-- Votre contenu commence ici -->
                Lorem ipsum dolor, sit amet, consectetur adipisicing elit.
                <!-- Votre contenu se termine ici -->
            </div>
        </div>
    </div>
</body>
</html>

J’ai fait une sorte de mire pour tester différentes couleurs de fond. Vous pouvez trouver le code ici.

Capture d’écran d’un test de mire dans Gmail iOS en mode sombre. En haut, avec le correctif, le texte blanc et la couleur de fond sont toujours conservés. En bas, sans le correctif, les couleurs sont changées par Gmail.

Conclusion

Je pense que le modes sombre est une avancée majeure en terme d’accessibilité et de préférences utilisateur. Et comme je le disais il y a déjà deux ans, « le mieux que vous puissiez faire est d’accepter ce choix plutôt que d’essayer de luttre contre ». Mais c’est aussi important de reconnaître quand les clients mail font n’importe quoi.

Je suis tout excité d’avoir réussi à trouver cette solution. Et même si ça reste limité (l’utilisation de mode de fusions limite ça a du texte blanc), j’espère que ce sera bien utile pour quiconque rencontre des difficultés avec le mode sombre de Gmail.

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

Dites bonjour à caniemail.com

En mars dernier, j’ai publié des idées pour Can I email, un site similaire à caniuse.com dédié au support dans les clients mails.

Aujourd’hui, à peine six mois après, je suis heureux et fier d’annoncer qu’avec l’aide de mes collègues et des membres de la communauté #emailgeeks, nous lançons officiellement caniemail.com.

Pour l’instant, nous avons plus de 50 fonctionnalités HTML et CSS testées sur 25 clients mails. Et on a plein de choses en réserve à venir dans les prochains mois.

Je suis aussi enchanté de pouvoir vous présenter le « tableau des scores » des clients mails. Pour la première fois, on peut voir un classement objectif des clients mails basés sur leur support de fonctionnalités HTML et CSS. J’espère que cela placera une nouvelle barre pour toute l’industrie et encouragera les moins bons élèves à s’améliorer.

Le site est fait par et pour la communauté des #emailgeeks. Toutes les données présentées sont disponibles sur GitHub de manière à ce que n’importe qui puisse les mettre à jour, les enrichir ou les contester. Vous pouvez jeter un oeil à notre guide de contribution. Et n’hésitez pas à me poser la moindre question si vous en avez.

J’espère que le site vous plaira et que vous y contribuerez de quelque manière que ce soit.

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

Aujourd’hui j’ai découvert la propriété mso-generic-font-family…

Et j’ai résolu un mystère d’Outlook vieux de douze ans au passage.

Ce matin, je faisais des tests dans Outlook sur les styles supportés dans les listes HTML. Et mon attention s’est vite détournée sur quelque chose qui n’a rien à voir. En utilisant le site What does it paste pour la première fois pour récupérer le code généré par Outlook et son moteur de rendu de Word, le <head> de l’e-mail contenait le code suivant :

<style> <!-- /* Font Definitions */
@font-face {
	font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-536859905 -1073732485 9 0 511 0;
}
</style>

@font-face ? Dans Outlook ? Qu’est-ce que cette diablerie ?

Si vous êtes habitués aux polices web dans les e-mails, vous savez surement qu’il y a un bug notable dans les Outlook (2007, 2010, 2013 and 2016) sur Windows. À chaque fois que vous importez une police web en utilisant une déclaration @font-face, Outlook l’ignore (comme on pourrait s’y attendre). Mais Outlook ignore alors aussi les polices alternatives définies dans vos styles, forçant tous les textes utilisant cette police web en Times New Roman. Prenez l’exemple suivant :

<!doctype html>
<html>
<head>
	<title>mso-generic-font-family</title>
	<link href="https://fonts.googleapis.com/css?family=Pacifico" rel="stylesheet" type="text/css" />
</head>
<body>
	<p style="font-family:Pacifico, sans-serif;">
		This is a text set in the <strong>Pacifico</strong> font.
	</p>
</body>
</html>

Outlook va irrémédiablement afficher ce texte en Times New Roman, ignorant l’alternative sans-serif définie dans la propriété font-family.

Captures d’écrans sur Email on Acid montrant le texte en Times New Roman sur Outlook 2016.

Plein de solutions ont été trouvées au fil des années pour éviter ce bug, de l’utilisation d’!important en ligne à la déclaration de la police à l’intérieur d’une media query. Ma solution préférée a toujours été de cacher l’appel à la police web aux yeux d’Outlook en utilisant un commentaire conditionnel comme dans l’exemple suivant.

<!--[if !mso]><!-- -->
<link href="https://fonts.googleapis.com/css?family=Pacifico" rel="stylesheet" type="text/css" />
<!--<![endif]-->

J’ai toujours trouvé ce comportement de Outlook bizarre (même pour Outlook, c’est dire). Mais cette solution fonctionnait suffisamment bien pour que je ne cherche jamais à creuser davantage. Et qui plus est, ce bug a été corrigé dans la dernière version d’Outlook (2019). L’affaire était donc classée pour moi. En tout cas c’est ce que je croyais.

Quand j’ai vu cette déclaration @font-face ajoutée par Outlook ce matin, je savais que j’étais tombé sur quelque chose. La ligne suivante, en particulier, a retenu mon attention :

mso-generic-font-family:swiss;

Je n’avais jamais entendu parlé de cette propriété. Mais le nom sonne vraiment comme quelque chose qui pourrait avoir un lien avec le comportement d’Outlook et des polices web.

J’ai donc repris mon premier exemple de test, j’ai déclaré ma police web dans une balise <style>, et j’ai ajouté cette propriété mso-generic-font-family.

<!doctype html>
<html>
<head>
	<title>mso-generic-font-family</title>
	<style>
		@font-face {
			font-family: 'Pacifico';
			font-style: normal;
			font-weight: 400;
			src: local('Pacifico Regular'), local('Pacifico-Regular'), url(https://www.caniemail.com/tests/assets/fonts/			pacifico-regular.woff2) format('woff2');
			mso-generic-font-family:swiss;
		}
	</style>
</head>
<body>
	<p style="font-family:Pacifico, sans-serif;">
		This is a text set in the <strong>Pacifico</strong> font.
	</p>
</body>
</html>

Et voilà !

Captures d’écrans sur Email on Acid montrant le texte en Arial sur Outlook 2016.

La propriété mso-generic-font-family accepte les valeurs suivantes :

  • decorative
  • modern
  • roman (correspondant à du serif)
  • script
  • swiss (correspondant à du sans-serif)
  • auto (correspondant à roman par défaut)

Ça explique tout. Outlook supporte bel et bien la déclaration @font-face (mais ne charge pas les polices distantes). Et parce qu’Outlook ne peut pas afficher pas cette police, il va chercher à se replier sur la valeur attendue de la propriété mso-generic-font-family. Et parce qu’elle n’est pas définie, on tombe sur sa valeur par défaut auto qui correspond à la famille roman, elle-même correspondant à du Times New Roman.

Affaire classée.

En creusant un peu plus à travers le code généré par Outlook et en lisant la documentation du HTML dans Outlook et Microsoft Office, je suis tombé sur une autre propriété nommée mso-font-alt. Cette propriété permet d’affiner encore un peu plus la police alternative dans Outlook en y attribuant le nom d’une autre police. En ajoutant les lignes suivantes à notre déclaration @font-face, Outlook va d’abord chercher à appliquer la police définie dans la propriété mso-font-alt (si elle est installée sur la machine) ou sinon appliquer la famille définie dans la propriété mso-generic-font-family.

mso-generic-font-family: swiss;
mso-font-alt: "Century Gothic";

J’espère que vous avez apprécié cette lecture autant que j’ai aimé faire ces recherches. Je me demande quand même s’il n’y aurait pas encore autre chose à creuser avec @font-face dans Outlook. N’y aurait-il pas moyen de charger des polices distantes ? Faites moi signe si vous trouvez quelque chose à ce sujet.

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

How To Target Email Clients

« Comment cibler les clients mails » est un site mis en place par Dylan Smith avec une liste d’exemples fournie par Mark Robbins pour cibler les clients mails spécifiquement.

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

Gmail compte 1,5 milliards d’utilisateurs

Vu le mois dernier :

1,5 milliards de personnes utilisent Gmail chaque mois, et 5 millions d’entreprises payent pour utiliser Gmail au travail au sein de G Suite.

En 2016, c’était 1 milliard.
En 2012, c’était 425 millions.

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

Garfield Mail

Vu sur Twitter :

Aujourd’hui j’ai appris qu’avant Google, G-Mail était un service gratuit du site de Garfield pour des « emails with cattitude ».

Je découvre aussi et ça me fait bien rire. Comme indiqué dans le tweet, le site est toujours visible sur Archive.org.

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

Comment Gmail a arrêté de supporter les animations CSS

Le saviez-vous ? Jusqu’à il n’y a pas si longtemps, Gmail supportait les animations CSS. Enfin, en quelque sorte. Jusqu’en juin 2016, la version desktop du webmail de Gmail supportait les déclarations @keyframes en CSS. Vous pouviez donc déclarer l’animation suivante dans une balise <style> dans le <head> de votre e‑mail, et Gmail la gardait telle quelle.

@keyframes foo {
    from { background:red; }
    to { background:black; }
}

Lire la suite de « Comment Gmail a arrêté de supporter les animations CSS »

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

L’accessibilité des e‑mails par l’exemple

On parle de plus en plus d’accessibilité dans les e‑mails ces dernières années, et c’est une très bonne chose. Mais je tombe toujours régulièrement sur plein d’e‑mails peu accessibles. En donnant des formations ou des conférences, je me suis rendu compte que montrer, et pas seulement expliquer, la différence que peut faire un e‑mail accessible était un excellent moyen pour sensibiliser des gens au sujet. Voici quatre conseils pour améliorer l’accessibilité dans l’intégration d’e‑mails, illustrés par des vidéos.

1. Toujours préciser l’attribut alt.

L’attribut alt de l’élément img est obligatoire depuis HTML 4. Cela signifie que chaque image d’un e‑mail doit avoir un attribut alt, même si celui-ci est vide (alt="").

Lire la suite de « L’accessibilité des e‑mails par l’exemple »

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

Outlook.com supporte désormais les images de fond en CSS

La nouvelle, rapportée par Justin Khoo chez Email on Acid, est aussi géniale qu’inattendue. Le webmail Outlook.com supporte désormais les images de fond en CSS. Cela inclut la propriété background, mais aussi ses déclinaisons background-image, background-repeat, background-size, background-position, background-color, background-origin, background-attachment. Et même (d’après mes tests) background-blend-mode.

Jusqu’à présent, la seule façon d’inclure des images de fond dans Outlook.com était via l’attribut background en HTML. Ça avait l’inconvénient d’obligatoirement répéter une image de fond et de ne pas pouvoir en choisir le positionnement ni la taille. Mais surtout de devoir être utilisé sur une <table> ou un <td>. Cette mise à jour de Microsoft (peut-être la plus importante d’un point de vue CSS depuis l’existence d’Outlook.com) est donc un pas dans la bonne direction, retirant une des dernières raisons d’utiliser des tableaux de mise en page dans les e-mails.

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

Corriger les problèmes de mises à l’échelle de Outlook (120 dpi)

Courtney Fantinato a donné une excellente conférence sur les problèmes de mises à l’échelle d’Outlook. (C’est ce qu’on retrouve communément dans Email on Acid ou Litmus sous l’appelation « Outlook 120 dpi »). Elle vient d’en faire un article très clair et didactique. En résumé, pour corriger les problèmes liés à des niveaux de mises à l’échelle personnalisés dans les Outlook sur Windows, il faut :

  1. Ajouter l’espace de nom de Microsoft Office sur la balise <html> : <html xmlns:o="urn:schemas-microsoft-com:office:office">.
  2. Ajouter la balise de définition des PixelsPerInch pour les images.
    <!--[if mso]>
    <xml>
      <o:OfficeDocumentSettings>
      <o:AllowPNG/>
      <o:PixelsPerInch>96</o:PixelsPerInch>
      </o:OfficeDocumentSettings>
    </xml>
    <![endif]-->
  3. Utiliser des dimensions en pixels en CSS plutôt que via des attributs HTML. (Par exemple, privilégier <table style="width:600px;"> plutôt que <table width="600">.)

 

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

Les images de fond et l’application e-mail de Samsung

Excellente trouvaille par Courtney Fantinato : l’application e-mail de Samsung sur Android n’affiche les images de fond si et uniquement si on écrit l’adresse de l’image entourée de guillemets simples. Des guillemets doubles ou pas de guillemet du tout ne fonctionneront pas.

background-image: url('background.jpg');

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

Le tout nouveau guide du support de CSS dans un e‑mail

Campaign Monitor a mis à jour son colossal guide du support de CSS dans un e‑mail, qui n’avait pas été mis à jour depuis 2014. C’est une ressource absolument précieuse à consulter et partager.

Je regrette un peu la nouvelle mise en page que je trouve moins lisible.

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

L’e‑mail interactif de Microsoft qui ne fonctionne sur aucun client mail de Microsoft

Justin Khoo a repéré un e-mail interactif de Microsoft. Modernité oblige, l’interactivité en question en fonctionne sur aucun client mail de Microsoft (à l’exception d’Outlook sur Mac qui, utilisant le moteur WebKit, fait toujours figure d’exception).

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

Email Camera

Cet article est la retranscription d’une présentation donnée à Litmus Live 2017 à Londres le 29 août lors de la session #EmailHacks présentée par Kevin Mandeville. Vous pouvez trouver mes slides ici et la démo de « l’Email Camera » ici. Une version en anglais de cet article est disponible.

J’aime beaucoup les jeux vidéo. Je suis un grand fan de Nintendo, en particulier du Game Boy. (Oui, on dit un Game Boy.) J’adore le Game Boy. C’était ma première console quand j’étais petit. Et maintenant j’en collectionne plein.

En 1998, Nintendo sort le Game Boy Camera. C’est une caméra numérique montée sur une cartouche de jeu. Elle peut prendre des photos en quatre niveaux de gris dans une résolution de 128 × 112 pixels. Et elle comprenait des jeux, filtres et était compatible avec le Game Boy Printer. Le Game Boy Camera transformait le Game Boy en machine à selfie ultime.

Il y a quelques mois, je trainais sur le Slack des #emailgeeks. À un moment, Kevin Mandeville a mentionné le Game Boy Camera. Et Jacques Corby-Tuech a répondu quelque chose du genre : « Un Game Boy Camera dans un e-mail. »

Ça a immédiatement fait tilt. Il fallait que je fasse ça. Si quelqu’un devait faire un e-mail inspiré par le Game Boy Camera, il fallait que ce soit moi. En plus, j’avais déjà le sentiment qu’utiliser la caméra dans un e-mail était possible depuis que j’avais vu cette démo sur CodePen.

C’est une démo de colorisation d’image dynamique qui utilise la pipette colorimétrique système et qui permet de changer la couleur de la voiture dans la photo. Et ça n’utilise pas du tout de JavaScript. C’est juste du HTML et CSS. C’est possible en grande partie grâce à l’élément suivant.

<input type="color" />

Ce qui est bien avec un <input type="color">, c’est que ça utilise la pipette colorimétrique système. Et les navigateurs compatibles affichent généralement un aperçu de la couleur sélectionnée.

Un exemple de pipette colorimétrique dans Chrome sur macOS

En utilisant un peu de CSS et des sélecteurs propriétaires comme ::-webkit-color-swatch et ::-webkit-color-swatch-wrapper, on peut retirer les bordures et marges intérieures de l’élément. Puis, en appliquant encore quelques styles, on peut redimensionner cet élément en plein écran. Et puis on peut placer une photo en dessous. Et en utilisant la propriété CSS mix-blend-mode:hue, on arrive au résultat souhaité.

Qu’est-ce que ça a à voir avec des e-mails et le Game Boy Camera ?

Et bien, il s’avère qu’on peut faire quelque chose d’équivalent avec l’élément suivant.

<input type="file" />

Un champ de type file permet de déposer des fichiers sur le Web. Et il y a deux choses particulièrement chouette à son égard :

1. Sur iOS ou Android, on peut importer un fichier directement depuis son appareil, ou utiliser l’appareil photo directement depuis là où on est pour prendre une photo.
2. Sur iOS, après avoir pris une photo, on obtient une toute petite miniature de 18 × 18 px.

À nouveau, en utilisant des sélecteurs propriétaires comme ::-webkit-file-upload-button, on peut masquer le bouton « Choisir un fichier ». On peut aussi tronquer l’élément pour ne laisser visible que l’image, et l’agrandir en utilisant une transformation CSS.

Un peu plus tard, le jour où le Game Boy Camera a été mentionné sur Slack, j’ai posté la vidéo suivante.

https://www.youtube.com/watch?v=A1ltAgkuIX4

Voici la démo complète disponible sur CodePen. Ça fonctionne bien dans Apple Mail sur iOS. Essayez et amusez-vous bien !

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

Le dernier bug d’Outlook.com (ou comment supprimer les marges sous les images)

Le mois dernier, Microsoft a introduit une nouvelle fonctionnalité dans Outlook.com et Office 365 qui a causé plein de problèmes aux intégrateurs et intégratrices d’e-mails. Il y a eu pas mal de discussions autour du sujet, que ce soit sur Slack ou les forums de Litmus. Ça m’a obsédé ces deux dernières semaines. Voici tout ce qu’il faut savoir sur ce bug et ma quête pour en trouver une solution.

Lire la suite de « Le dernier bug d’Outlook.com (ou comment supprimer les marges sous les images) »

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

Faut-il arrêter d’écrire ses styles en ligne dans des e‑mails ?

Jusqu’à l’an dernier, Gmail était l’un des plus gros clients mail ne supportant (presque) que des styles en ligne. Les webmails de Yahoo, AOL, Outlook.com et, oui, même les versions d’Outlook (de 2007 à 2016 sur Windows) utilisant le moteur de Word supportent les balises <style> depuis longtemps. La mise à jour de Gmail en 2016 a tout changé en ajoutant enfin officiellement le support de balises <style> et d’attributs class et id. Alors en 2017, faut-il arrêter d’écrire ses styles en ligne dans des e‑mails ?

La question est réapparue le mois dernier quand Kevin Mandeville de Litmus a partagé son retour expliquant pourquoi Litmus n’a pas utilisé de styles en ligne dans sa première newsletter de l’année. Si ça a beaucoup de sens pour Litmus et leur audience, et s’ils ont fait un bon travail pour s’assurer d’un bon rendu dégradé, je ne suis pas sûr qu’il soit encore temps de recommander à tout le monde d’arrêter d’utiliser des styles en ligne.

Voici quelques points à prendre en compte, avec des pours et des contres.

Lire la suite de « Faut-il arrêter d’écrire ses styles en ligne dans des e‑mails ? »

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

Les webmails « préférés » des français en novembre 2016

Le Journal du Net a publié une nouvelle version de son classement des « webmails préférés des français », où par « préférés » ils veulent toujours dire « les plus utilisés ». Le dernier classement datait de mars 2015, et la comparaison est intéressante. Les mesures ont été prises en novembre 2016 via une mesure panel de Médiamétrie.

  1. Gmail, 12,8 millions de visiteurs uniques (contre 11,24 en mars 2015)
  2. Orange, 12,6 millions de visiteurs uniques (contre 11,9 en mars 2015)
  3. Outlook.com, 9,4 millions de visiteurs uniques (contre 8,9 en mars 2015)
  4. SFR, 4,4 millions de visiteurs uniques (contre 4,29 en mars 2015)
  5. Yahoo, 4 millions de visiteurs uniques (contre 3,95 en mars 2015)

Pour la première fois, Orange perd sa place de numéro un au profit de Gmail.

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

Quel doctype faut-il utiliser dans un e‑mail ?

Le doctype est la toute première ligne de n’importe quel document HTML. Mais savez-vous quel doctype utiliser et pourquoi ? Voici ma tentative d’expliquer tout ce qu’il faut savoir sur les doctypes pour des e‑mails HTML.

Lire la suite de « Quel doctype faut-il utiliser dans un e‑mail ? »

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

Le démineur dans un e‑mail

Réalisé par Camille Palu de TABLE TR TD, ce démineur dans un e‑mail fonctionne vraiment (avec décompte du temps, écran de victoire…). Comme beaucoup d’e-mails interactifs, ça utilise principalement des cases à cocher, et ça ne fonctionne quasiment que dans Apple Mail. Mais c’est quand même un belle démo technique.

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

Gmail va supporter la balise <style>, les media queries, les classes et plein d’autres trucs

La nouvelle secoue la communauté des développeurs et designers d’e-mails depuis hier : Google va supporter le Responsive Design « plus tard ce mois-ci ». Ça signifie support des balises <style>, des media queries, des attributs class et id en HTML. Google a mis en ligne des pages pour expliquer le support de CSS, et aussi une liste des media queries et propriétés CSS supportées.

Et la liste est particulièrement intéressante, avec notamment des propriétés CSS avancées comme background-blend-mode, columns, mix-blend-mode, object-fit, object-position, …

C’est vraiment une excellente nouvelle, et un immense bouleversement dans le monde de l’intégration d’e-mails. Certains annoncent déjà la fin de l’utilisation des styles en ligne (au profit uniquement de la balise <style>) et des méthodes fluide/hybride ou la technique des Fab Four. Mais je ne pense pas, car il reste encore un paquet de clients e-mails ne supportant ni les balises <style>, ni les media queries. (Coucou le nouvel Outlook.com !)

Mes principales interrogations à l’heure actuelle sont les suivantes :

  • Quelles versions de Gmail seront concernées ? L’annonce de Google indique que ça concerne « Gmail et Inbox by Gmail ». Mais j’expliquais le mois dernier que le support de CSS dans Gmail est bien plus nuancé que ça. Est-ce que ça concernera aussi les versions de Google Apps for Work et les comptes tiers dans Gmail sur Android ?
  • Quid du support des valeurs en CSS ? Est-ce qu’on pourra toujours utiliser calc(), linear-gradient(), etc. Est-ce qu’on aura également toujours le support de sélecteurs comme :hover, :first-child, etc. ?

Réponse d’ici deux semaines.