Hi,
Happy New Year! One of my goals for 2016 is to consistently send this newsletter twice a month. That was my target at launch. But I missed it every month.
So here's the first newsletter. In this issue, I wanted to go back to basics and examine images, which are more complicated in Email. I want to share with you my approach to images. Basically we'll look at creating responsive images without media queries.
I love hearing your feedback and more importantly, sharing it back with everyone on this list. This month I want to thank Rémi Parmentier and Kevin Mandeville for sharing and expanding on last issue's topic of Outlook bugs (details below). What will you send this issue?
Cheers
Julie
P.S.
Do you find this newsletter useful? If so, can you do me a favor and forward this to friends and colleagues? Thanks!
Issue #4
 |
Follow up: Outlook.com Selector Bug
|
|
Back to Basics: Images
|
|
|
I. Follow Up: Outlook.com Selector Bugs
|
Last issue, I mentioned that the Outlook.com parser ignores certain selectors, which is why I do not use .header, .footer, and other common selector names. But I did not see a pattern amongst the affected names.
Afterwards, reader Rémi Parmentier did some debugging and discovered that the affected class names are not random, but corresponds with HTML tag names, e.g. nav and label. See his full explanation here.
Thanks Rémi for the full explanation of this issue.
|
|
|
|
Related: Litmus Tests use OWA
|
I had trouble confirming this bug during testing. But Kevin Mandeville from Litmus confirmed to me that Litmus uses the latest Outlook Web App (OWA), which has improved rendering, in their tests.
Although Microsoft has indicated they will migrate everyone to OWA, my impression is that it hasn't started yet in Europe - or at least Germany yet. Fun fact: many Germans (incl. several friends of mine) still have Hotmail addresses.
Depending on your audience, you might not encounter this bug.
Thanks again to Rémi and Kevin for sharing. If you have something to add, write me and I'll share it with everyone.
|
|
II. Back to Basics: Images
|
When I started this newsletter, I also wanted to re-cover the basics. Many of us write HTML every day and can probably do it in our sleep! But Email HTML is different and in many ways, it's like going back in time and coding like it's 1999.
This is a pain. But we can also look at it as a chance to better understand how HTML elements inherently behave (before you CSS framework the hell out of them). In this way we will better understand HTML and this will help us develop bullet proof emails.
|
<img>
Back to Basics
|
In this issue, we'll look at images in Email and common conventions, including which ones you should re-consider.
|
|
Basic Tag
|
|
If you examine most HTML emails, you will probably see something like this:
|
|
<img src="photo.jpg" width="600" height="100" border="0" alt="My Company Name">
|
|
with the following attributes:
|
src - always set and use full http:// reference.
|
|
width - always set
|
|
height - optional
|
|
alt - always set
|
|
The challenge with images in Email is knowing what to set and when to set it. So, let's first look at why we need certain attributes, in order of importance or influence.
|
|
Always set the alt attribute
|
Per the W3C spec, alt stands for alternate text Many clients, including Microsoft Outlook default to blocking images, in which case your alt attribute will be displayed as text. You should ALWAYS set set this attribute - unless it's a spacer image, in which case you still want empty alt="" per the W3C spec.
Of course, if you wish, you can also style the alt text. But that's a topic for another day.
|
|
Retina and HD Images
|
A beautifully coded email can feel ruined by fuzzy images because the sender didn't think about HD images.
Omitting dimensions from the img tag is not a problem - if they are sized at 1x. But because we want to support HD devices, most of our images are @2x. Many email clients will display images at their native widths and heights if you do not specify them explicitly.
Ok, so we must specify image dimensions. But how do we do that and also support variable screen sizes from phones, which suggest widths as percentages to desktop clients like Outlook, which only supports pixel widths?
Percentages or pixels? Answer: both.
|
|
Image Widths
|
Here is how I usually go about setting my image dimensions:
1. Use pixel values for the width attribute on the <img> tag.
I often start with the lowest common denominator: Microsoft Outlook.
In my experience Outlook 2007/10/13 prefers the width attribute on the <img> tag, over the css width attribute. For this reason, use the desktop full width pixel value when setting the width attribute on the image.
2. Also set width with CSS.
In most cases, you will set the width in pixel values, for example:
|
Images that are part of layout and design, e.g. logos
|
|
UI images, e.g. social icons, visual dividers
|
|
But in other cases you will want to set percentage values. A common use case is images wrapped by text, for example in articles. Here is a simplified code example <img> tag for such cases:
|
|
<img src="photo.jpg" align="right" alt="caption" width="150" style="width:25%">
Article text goes here…
|
|
Note that 150 pixels is 25% of a 600px layout width. Again, this is simplified. In many cases, you will have wrapper tables that also require widths set in both HTML attributes and CSS. But the strategy is similar.
|
|
|
In addition to setting the width attribute in HTMl, you will want to set various width properties in CSS.
|
In the example above, we have a right-aligned image. We use a percentage width, which gives us sensible values for most devices. This way, I don't have to worry about various tablet and large phone sizes. But I still need to account for the too extremes below.
3. Set max-width with CSS.
As an extra precaution to prevent layouts from breaking, in case your email service provider (ESP) adjusts image dimensions, set max-width:100%. This ensures that the image will not stretch its parent container.
4. Set min-width with CSS.
Because Gmail will remove the width attribute in CSS (and HTML too in mobile Gmail app) on your images, you may also want to set min-width. Because I usually use high resolution @2x images and I set max-width:100%, the email layouts do not break.
Although the images don't stretch, sometimes they shrink too much. So for social icons and images wrapped by text, I set an appropriate min-width to make sure the images are recognizable. For example, you want to make user profile photos have recognizable faces.
|
|
Image Heights
|
In my workflow, I usually leave out the height attribute on the <img> tag because:
|
Some images have percentage widths so I prefer to let the email client or browser calculate the height. Even Outlook does this correctly.
|
|
Without a height, mobile email clients will use minimal height on images that have not loaded. This reveals more text content to the user above the fold.
|
|
|
| Unloaded images with heights looks like empty content (Not Recommended) |
|
| Unloaded images without heights reveal more content (Recommended) |
|
Caveat: many ESPs, including Campaign Monitor will add a height attribute on the <img> tag for you.
This results in stretched images in the Gmail app, even if you use height:auto because Gmail adjusts it to min-height:auto, which means if you have a height value meant for desktop, the images will be stretched on mobile. To read more on this issue, see this article by Stephen Jesson.
Stephen does not have a solution for this problem. Neither do I. Do you? If so, send me an email and let's share it with everyone.
|
|
Layout: display:block
|
Lastly, I wanted to add that many ESPs and tutorials recommend setting all images to display:block. This is especially useful in images that are part of the design, for example: city skyline in an email footer.
Without display:block, you may have a 1px pixel gap between the image and the footer, esp. in Gmail.
But I do not recommend blindly inlining display:block or including img { display:block !important; } in your emails. In some cases, I find using display:inline-block useful when I have repeating dynamic images and I want to line them up without HTML <table> spaghetti code to support Outlook.
|
|
Anything else?
|
At some point I have to stop writing or I'll never send this newsletter out ;-) I wanted to go into more detail on some issues. But I will consider doing that in a blog post instead.
Did I miss something? Got a question about images in Email you always wanted to ask? Reply to this email and let me know! I read every email - and try to respond to each one too.
|
