Un email responsive avec Ink

Cet article présente des techniques de construction d’emails HTML et responsive avec le framework Ink en partant d’un cas d’utilisation général puis en détaillant les ajustements qui ont été nécessaires pour une mise en place spécifique.

Problématique de communication récurrente et sans solution miracle, habiller élégamment ses emails reste une épreuve d’autant plus grande à l’heure du responsive web design. Les techniques de construction d’emails HTML et responsive web design se sont développées grâce à la persévérance de pionniers qui ont surmontés les contraintes techniques jusqu’à obtenir le rendu voulu. Aujourd’hui, cette expérience est en partie capitalisée à travers documents et outils, et je vais vous parler d’un de ces outils : Ink.

Introduction

Le sujet des emails responsive à déjà été traité dans l’article « un email responsive, c’est possible » publié sur notre blog. Dans le présent article, je vais essayer d’aller plus loin en détaillant mon expérience avec l’outil Ink et en proposant d’autres techniques de rendus. Les astuces et fragments de code présentés sont compatibles avec les principaux clients mails Apple Mail (Desktop et iOS), Outlook (2000, 2002, 2003, 2007, 2010, 2011, 2013), Thunderbird, Android, Gmail (Desktop, Mobile, iOS, Android), AOL Mail, Hotmail, Outlook.com. Une exception est faite pour Lotus Note. Dans la mesure où son comportement est très atypique et où le logiciel est utilisé dans un contexte quasi exclusivement professionnel, il nécessite un effort trop situationnel et ne sera pas traité dans cet article.

Ink est proposé à travers un template d’email responsive qui contient une structure HTML et du code CSS initial ayant un large panel de clients mails compatibles. Une fois le template téléchargé et prêt à être complété, la documentation de Ink explique comment mettre en œuvre les outils prévus par le CSS du framwork : grille, sous grille, panneaux, boutons, etc. L’utilisateur est alors prêt à produire un email qui s’adapte au rendu desktop et mobile. Ayant uniquement testé la grille de Ink, je ne m’étendrai pas sur l’utilisation des autres outils proposés. Le template et la grille responsive méritent-ils à eux seuls cet article ? Je le pense.

Ink : cas standard

Dans un cas standard, votre contenu HTML avec Ink devrait être organisé de la façon suivante :

<table class="body">
    <tr>
      <td class="center" align="center" valign="top">
        <center>

          <table class="row">
            <tr>
              <td class="center" align="center">
                <center>

                  <table class="container" style="background-color:gray">
                    <tr>
< !-- Un wrapper pour chaque columns, quelle que soit la largeur. 
Le dernier wrapper doit aussi avoir la classe last -->
                      <td class="wrapper">
                        <table class="six columns">
                          <tr>
                            <td class="left-text-pad">
                              <img src="http://placehold.it/200x50">
                            </td>
                            <td class="expander"></td>
                          </tr>
                        </table>
                      </td>
                      <td class="wrapper last">

                        <table class="six columns">
                          <tr>
                            <td class="left-text-pad-mobile">
                              <img src="http://placehold.it/200x50">
                            </td>
                            <td class="expander"></td>
                          </tr>
                        </table>

                      </td>
                    </tr>
                  </table>

                </center>
              </td>
            </tr>
          </table>

< !-- Répéter ici le motif à partir de row ou de container directement -->

         </center>
      </td>
   </tr>
</table>

Aperçu du rendu (768px de large) :

Aperçu du rendu (300px de large) :

La table de classe row, en orange clair dans le code, est optionnelle et pourra être utilisée si deux contenus consécutifs ont une largeur totale inférieure ou égale aux 580px et s’ils ne doivent pas s’afficher côte à côte. La classe row forcera alors le passage à la ligne. Dans tous les autres cas, la table row n’est pas utile et le passage à la ligne sera automatique. En dehors de ça, body sert à encadrer le bloc. Ne pas hésiter à faire plusieurs body pour bien séparer les différentes parties de vos emails et éviter le bug de saut de page outlook 2007 et 2010. Ensuite, container vous permet d’indiquer une colonne de contenu. La classe sert à maîtriser la largeur d’affichage fixe en desktop, et de largeur fluide par défaut en mobile. Chaque container pourra contenir autant de colonnes que nécessaire. Pour chaque colonne, indiquez la classe wrapper au td, puis définissez une largeur de type six columns au tableau en dessous. Le chiffre avec column fixera la largeur et les wrapper et wrapper last s’occuperont des marges en rendu desktop, et d’empiler les blocks correctement en rendu mobile. En l’état, ce code est compatible avec tous les principaux clients mails cités en introduction.

Mise en œuvre contextuelle

La grille

La grille initiale de Ink est prévue pour une largeur desktop de 580px. Cette largeur permet un résultat optimal dans les webmails en considérant la « pire » situation desktop : résolution de 1024px et barres de navigation et de publicité autour des mails. La grille prévue est de 12 colonnes de 30px séparées par 11 marges de 20px (12×30 + 11×20 soit 580px, le compte est bon). Cependant, les maquettes à partir desquelles j’ai travaillé étaient prévues en 10 colonnes et 11 marges (2 gouttières autour mais pas toujours utilisées) de 10px et sur une largeur totale de 600px, soit 20px de plus que la largeur de base.

Exemple sur Yahoo mail d’un rendu 580px et 600px pour une zone d’afichage de 1024px :

La grille initiale de Ink ne se prêtait donc que moyennement à la configuration voulue, mais j’ai pu faire les changements suivants : grille de 10 colonnes de 50px chacune suivie de 1 gouttière de 10px (10 * 60 = 600px). Pour la première gouttière, comme elle n’est pas systématiquement utilisée et toujours associée à la gouttière finale, j’ai refais les calculs de largeur de manière spécifique pour les endroits où c’était nécessaire. Certains blocs ont donc pris des largeurs spécifiques, d’autres les valeurs de la grille, ce qui n’a finalement posé aucun problème au moment de passer le tout en responsive.

Largeur du contenu mobile

Par défaut, le contenu est centré et prend une largeur de 600px si la zone d’affichage est supérieure ou égale à 600px. En dessous de 599px inclu, on considère un rendu mobile et le contenu passe en largeur fluide. Le contenu occupe 95 % de l’espace disponible créant ainsi des petites marges sur les côtés (le contenu est toujours centré). Encore une fois cela ne correspondait pas au résultat souhaité qui était d’avoir une largeur fixe à 300px dès le point de rupture dépassé. Cette fois également, j’ai pu adapter le code du framework pour indiquer à mes conteneurs de prendre une largeur de 100 %, et j’ai introduit une nouvelle classe permettant de fixer la largeur du contenu à 300px en rendu mobile. Tout à la fin de @media only screen and (max-width : 600px), ajouter :

table[class="body"] .mobilenarrow {
   width : 300px !important ;
}

Il est important que ce code soit ajouté à la fin pour des raisons de priorité CSS. Cette classe peut ensuite être utilisée à deux endroits dans la structure de Ink : sur les éléments container et sur les column. Ces éléments possèdent des margin : 0 auto ; et sont donc centrés automatiquement dans leur parent. On voudra utiliser mobilenarrow sur un container pour que le background soit redimensionné à 300px mais on pourra préférer le mettre sur le column pour avoir un fond occupant toute la largeur (fluide), tout en gardant un contenu limité à 300px centré.

Exemple de rendu des largeurs fixes sur mobile (320px) :

Dernier ajustement pour que mobilenarrow fonctionne : en mobile, Ink positionne un display : block sur les row, ce qui altère le rendu voulu. Dans la mesure où les row sont prévues en largeur 100 %, passer le display en block n’est pas nécessaire pour assurer un passage sur une nouvelle ligne. Il conviendra donc de remplacer row par un div ayant uniquement width:100 %, de ne pas utiliser row du tout si ce n’est pas nécessaire, ou enfin de supprimer le display:block des row. Je n’ai pas noté de changement sur les rendus via Litmus (outil de tests d’emails responsive) en faisant cette dernière modification. Il est bon de noter que tous ces ajustements pour le rendu mobile n’ont aucune conséquence sur le rendu desktop.

Oubliez les margins

Si vous ciblez Outlook.com, la propriété CSS margin n’est pas utilisable. Tout le CSS lié aux margins sera purement et simplement supprimé. Il conviendra donc d’utiliser des paddings. Mais attention ! Sous Outlook 2007, 2010 et 2013 les paddings ne sont pas supportés pour les balises « p » et « div ». Solution : utiliser des paddings sur vos td pour gérer vos espacements. Par défaut, Ink propose la ligne suivante comme reset de style : table, tr, td { padding : 0 ;}. Dans la mesure où il est nécessaire d’utiliser un inliner pour les clients webmails, le padding:0 par défaut n’est pas souhaitable pour pouvoir le modifier facilement. Aussi, il est plus sûr de ne pas donner de valeur de reset. A ma connaissance aucun client mail n’a de valeur autre que 0 pour le padding par défaut des td, tr et table. Si vraiment vous ne pouviez pas gérer vos espacement verticaux avec des paddings de cellule, une alternative est d’utiliser une image d’un pixel transparent, en veillant à ce qu’elle soit display:block :

Inliner + mobile, c’est !important

J’ai évoqué à l’instant l’inliner, cet outil qui permet de prendre les styles du <head> pour le placer directement dans l’attribut style des balises, permettant ainsi le rendu correct sur les webmails qui suppriment systématiquement le contenu du <head>. Les styles mobiles déclarés dans <head> ne sont pas repris par le inliner car ils dépendent de media queries et ne peuvent être intégrés directement. Aussi, pour surpasser la priorité CSS du style inline posé à l’intention des webmails, la seule option pour les styles mobiles des media queries est de devenir !important. Ink le fait déjà pour toutes ses classes du framework, mais n’oubliez pas de le faire pour les votre afin que vos styles mobiles continuent de fonctionner après passage de l’inliner.

Hide for desktop

Dernier point, Ink propose une classe par défaut .hide-for-dektop. Si vous ciblez Gmail desktop, ne l’utilisez pas ! Ni aucun display : none ! En effet, il n’est pas possible de masquer du contenu pour desktop. Ou plutôt, il en existe une, mais cette astuce ne fonctionne que pour un remplacement d’image. Pour plus de détails, je vous invite à consulter l’article « Un email responsive, c’est possible » qui dédie un paragraphe au sujet.

Conclusion

Faut-il utiliser Ink ? Ink est un outil pratique et qui pose des bases saines pour écrire son email responsive. Les choix initiaux ne conviendront pas à toutes les situations, mais l’outil est suffisamment simple et souple pour être adapté au besoin. Cela étant, ce n’est pas une solution miracle : il n’y en a pas. Il reste nécessaire de tester beaucoup et de s’adapter au mieux aux cibles souhaitées. Ink vous permettra de démarrer votre projet rapidement, voire de réussir à moindre effort un email simple si vous utilisez uniquement les briques proposées dans le framework. En revanche, ne pensez pas pouvoir vous affranchir d’apprendre les spécificités de l’email responsive si vous avez une idée très précise de ce que vous souhaitez réaliser.