Replace a desktop image with a responsive version in an email

Issue: Have you ever coded a responsive email? Yes ? Okay. Now, have you ever coded a responsive email with a layout specific to the desktop display, and a design specific to the responsive version? Also? So, assuming that email had links on multiple images, you probably went with one of the following:

Temporary solutions:

1. The tag tag of the responsive version is after the of the desktop version.

The image of the responsive version is not displayed on the desktop version using many CSS properties, it will be displayed in responsive with the appropriate class. The image of the desktop version will be "hidden" on the responsive version with the appropriate class.

<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>

The media queries are thus presented as follows:

@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;
}
}

We have schematically, in this solution, two still images.

This solution has several disadvantages: heavier HTML code, more complex and not very readable media queries, the need to fill in the link twice (the one around the image of the desktop version and the one around the image of the responsive version). If you have to repeat this operation for several images, you may quickly lose your footing... However, it has the advantage of being able to fill in a different link depending on the resolution of the medium.

2. The tag of the desktop version is included in a tag, where only one link will be filled in.

In the media queries, you indicate that, under a certain resolution, the image will be hidden, and that the tag becomes a "block" type element. Then, still in the media queries, you specify a fixed width and height for this "inline" type element, as well as a background image (the image specific to the responsive version).

<td id="“imageresponsive”">

<a href="/en/“/#lien”" target="“_blank”"><img style="“display:block;”" src="imagedesktop.jpg" class= "“hideOnMobile" /></a>

</td>

The media queries are thus presented as follows:

@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;
}
}

Here, we have only one fixed image, with one link. This solution does not allow to consider a different link for the responsive version of the link of the desktop version. However, it has the merit of simplifying the code slightly. Well, especially for the HTML part. Because it is still very confusing for the CSS and media queries. Again, if several images are to be modified in this way, it becomes very quickly "loaded" in terms of media queries, don't you think?

There are undoubtedly other techniques, sometimes more "dirty" or even more brutal. I still opt for the second one.

Alternative: A few years ago though (in 2012 exactly), I was looking for an alternative to this one. Naively, I thought that the solution could be found in javascript. A light script would have allowed to target the "id" of the desktop images and to modify the "src" attribute of these images according to the detected resolution. But we know that javascript is not recommended in an emailing. First of all, because it could affect the deliverability of the campaignbut also because it would probably not be not supported by all webmails and email programs.

Then I found on the Stackoverflow forum a solution issued by Pacerier, whose direct link I am providing here: https://stackoverflow.com/questions/2182716/is-it-possible-to-set-the-equivalent-of-a-src-attribute-of-an-img-tag-in-css
I learned that it was possible to "change" the "src" attribute using CSS. The content: url("") property could answer this request... This property, defined in CSS 2.1, could originally be applied exclusively to the :before or :after pseudo-elements. But the module " CSS3 Generated and Replaced Content"now states that this property can be applied to all elements.

At the time, I did not choose this solution. It was probably not supported in the same way. But today, I would like to take a closer look at it. Of course, it still implies the presence of media queries. But if Gmail (among others) evolves in terms of media queries support, why not try it? See for yourself how much more readable it is:

<a href="/en/“lien”/" target="“_blank”"><img src="imagedesktop.jpg" class="imageamodifier" /></a>

The media queries are thus presented as follows:

@media screen and (max-width: 600px) {
.imageamodifier{
content:url("imageresponsive.jpg");
}
}

In terms of readability and understanding of the code, it is difficult to do better, this is already the main advantage of this alternative. No background image is necessary, and even better: we can now enter percentage widths in the media queries so that we no longer use a fixed width for our responsive version but an ideal hybrid of fluid/responsive. The only drawback is the unique link, which cannot be modified for the responsive version.

Conclusion: According to my current tests on Litmus and EmailonacidThe result is convincing on all webmails and mail programs (and yet, my first tests were based on a Doctype 1.0 Transitional!), with the exception of Gmail App Android. However, I don't think the problem lies in the code itself, but rather in the updating of Gmail's many "types". As you can see hereGmail Android app with a POP/IMAP account is not yet up to date. So I guess we'll just have to wait and see how soon we can use this solution... without moderation!