Problématique : Avez-vous déjà codé un email responsive ? Oui ? Ok. Maintenant, avez-vous déjà codé un email responsive avec une maquette propre à l’affichage desktop, et un design spécifique à la version responsive ? Aussi ? Alors, dans l’hypothèse où cet email comportait des liens sur plusieurs images, vous avez probablement opté pour une des solutions suivantes :
Solutions temporaires :
1. La balise ![]()
de la version responsive est à la suite de la balise ![]()
de la version desktop.
L’image de la version responsive n’est pas affichée sur la version desktop à l’aide de nombreuses propriétés CSS, elle s’affichera en responsive avec la class appropriée. L’image de la version desktop, quant à elle, sera « cachée » sur la version responsive avec la classe appropriée.
<p class="showOnMobile" style="display:none; width:0; height:0; max-height:0; line-height:0; opacity:0; overflow:hidden; font-size:0; margin:0; padding:0;">
<a href="#lien" target="_blank"><img border="0" class="showOnMobile" src="imageresponsive.jpg" style="display:none; width:0; height:0; max-height:0; line-height:0; opacity:0; overflow:hidden; font-size:0;" /></a>
</p>
<a href="#lien" target="_blank"><img border="0" class="hideOnMobile" src="imagedesktop.jpg" style="display:block" /></a>
Les media queries se présentent donc ainsi :
@media screen and (max-width: 600px) {
body[yahoo] .showOnMobile {
display:block !important;
width:100% !important;
height:auto !important;
max-height:none !important;
line-height:100% !important;
opacity:1 !important;
overflow:visible !important;
font-size:inherit !important;
}
body[yahoo] .hideOnMobile {
display:none !important;
width:0 !important;
height:0 !important;
max-height:0 !important;
line-height:0 !important;
opacity:0 !important;
overflow:hidden !important;
font-size:0 !important;
}
}Nous avons schématiquement, dans cette solution, deux images fixes.
Cette solution présente plusieurs inconvénients : un code HTML plus lourd, des media queries plus complexes et peu lisibles, le besoin de renseigner deux fois le lien (celui autour de l’image de la version desktop et celui autour de l’image de la version responsive). Si vous devez répéter cette opération pour plusieurs images, vous risquez de vite perdre pied… Cependant, elle présente l’avantage de pouvoir renseigner un lien différent selon la résolution du support.
2. La balise ![]()
de la version desktop est comprise dans une balise, où un seul lien sera renseigné.
Dans les media queries, vous indiquez que, sous une certaine résolution, l’image sera cachée, et que la balise devient un élément de type « block ». Vous renseignez alors, toujours dans ces media queries, une largeur et une hauteur fixe à cet élément de type « inline » à la base, ainsi qu’une image de fond (l’image propre à la version responsive).
<td id=“imageresponsive”>
<a href=“#lien” target=“_blank”><img style=“display:block;” src="imagedesktop.jpg" class= “hideOnMobile /></a>
</td>Les media queries se présentent donc ainsi :
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
@media screen and (max-width: 600px) {
td[id=imageresponsive] {
background-image: url(imageresponsive.jpg) !important;
background-repeat: no-repeat !important;
background-position: center !important;
width: 300px !important;
height: 250px !important;
}
td[id=imageresponsive] a {
display:block;
width: 300px !important;
height: 250px !important;
}
img[class=hideOnMobile] {
display: none !important;
}
}Ici, nous n’avons donc qu’une seule image fixe, avec un seul lien. Cette solution ne permet pas d’envisager un lien différent pour la version responsive du lien de la version desktop. Cependant, elle a le mérite de simplifier légèrement le code. Enfin, surtout pour la partie HTML. Car cela reste encore très confus au niveau du CSS et des media queries. De nouveau, si plusieurs images sont à modifier de la sorte, cela devient très rapidement « chargé » sur le plan des media queries, vous ne trouvez pas ?
Il existe sans doute d’autres techniques, parfois plus « sales » ou plus brutales encore. J’opte encore aujourd’hui pour la seconde.
Alternative : Il y a de cela quelques années pourtant (en 2012 exactement), je cherchais une alternative à celle-ci. Naïvement, je pensais que la solution se trouvait peut-être dans le javascript. Un léger script aurait permis de cibler les « id » des images desktop et de modifier l’attribut « src » de ces images selon la résolution détectée. Mais nous savons bien que le javascript est vivement déconseillé dans un emailing. Tout d’abord, parce qu’il risquerait de nuire à la délivrabilité de la campagne, mais aussi parce qu’il ne serait probablement pas supporté par tous les webmails et logiciels de messagerie.
Je tombais alors, sur le forum Stackoverflow, sur une solution émise par Pacerier dont je vous communique ici le lien direct : https://stackoverflow.com/questions/2182716/is-it-possible-to-set-the-equivalent-of-a-src-attribute-of-an-img-tag-in-css
J’y apprenais donc qu’il était possible de réaliser un « changement » de l’attribut « src » à l’aide du CSS. La propriété content: url(«») pourrait donc répondre à cette demande… Cette propriété, définie en CSS 2.1, pouvait à l’origine être appliquée exclusivement au pseudo-éléments :before ou :after. Mais le module « CSS3 Generated and Replaced Content» affirme désormais que cette propriété peut être appliquée à tous les éléments.
A l’époque, je n’avais pas retenu cette solution. Celle-ci n’était probablement pas supportée de la même façon. Mais aujourd’hui, j’aimerai m’y attarder un peu plus. Bien sûr, cela implique toujours la présence de media queries. Mais si Gmail (entre autre) évolue quant au support des media queries, pourquoi ne pas essayer ? Constatez par vous-même le gain de lisibilité :
<a href=“lien” target=“_blank”><img src="imagedesktop.jpg" class="imageamodifier" /></a>Les media queries se présentent donc ainsi :
@media screen and (max-width: 600px) {
.imageamodifier{
content:url("imageresponsive.jpg");
}
}En termes de lisibilité et de compréhension du code, on peut difficilement faire mieux, c’est déjà le principal avantage de cette alternative. Aucune image de fond n’est nécessaire, et mieux encore : On peut désormais renseigner des largeurs en pourcentage dans les media queries pour ne plus se baser sur une largeur fixe pour notre version responsive mais un hybride idéal de fluide/responsive. Le seul inconvénient réside dans le lien unique, qui ne peut être modifié pour la version responsive.
Conclusion : Selon mes tests actuels sur Litmus et Emailonacid, le résultat est probant sur l’ensemble des webmails et logiciels de messagerie (et pourtant, mes premiers tests s’appuyaient sur un Doctype 1.0 Transitionnal !), à l’exception de Gmail App Android. Pourtant, je ne pense pas que le problème vienne du code à proprement parler mais plutôt de la mise à jour des nombreux « types » de Gmail. Comme vous pourrez le constater ici, Gmail Android app avec un compte POP/IMAP n’est pas encore à jour. Je pense donc qu’il ne reste plus qu’à patienter pour pouvoir bientôt utiliser cette solution… sans modération !
