While hardly breaking news, the appearance of gaps underneath images in Hotmail (and more recently, Gmail and Yahoo!) is still an issue. It’s also been well-covered by many of our friends and partners in the email world. For designers and marketers new to the quirks of creating HTML emails, here’s a quick overview:
GAPS, SPACES, BORDERS, MARGINS, OH MY!
No matter what you decide to call them, the result is still the same: about 3px of space appearing under images in your email design. These gaps can be especially apparent in designs where the layout consists of several images sliced apart and pieced back together in a table-based design:
Originally surfacing in Hotmail viewed in Firefox, the issue seems to be slowly spreading to all browsers and most webmail providers. Based on recent testing, we’ve seen gaps appear in both Mac and PC versions of all modern browsers (IE, Firefox, Safari, Opera and Chrome) when used to view emails sent to Hotmail, Gmail and Yahoo! accounts.
The great news is that there’s an easy fix. Depending on your coding style and the ESP or mailing software you use, there are a few things you should be aware of.
USING AN INLINE STYLE
Your first option is the most time-consuming, but it’s also the most reliable when used consistently. This involves addingstyle=”display: block” to each <img> tag in your HTML, like so:
<img src=”http://litmus.com/images/logo-shadow.png” height=”47″ width=”119″ border=”0″ alt=”Litmus” style=”display: block;”>
For folks that write their HTML in TextMate, I’ve created a handy snippet that includes placeholders for all the crucial bits to include in your <img> tags, including the style=”display: block” fix. This way I save time from repetitive keystrokes and never forget to include the fix. Here’s what the syntax for my snippet looks like:
<img src=”$1″ width=”$2″ height=”$3″ border=”0″ alt=”$4″ style=”display: block;”>
The $ indicators automatically move my cursor along, too!
USING AN EMBEDDED STYLE
Rather than manually adding the fix to each <img> tag, you can also include the following in the beginning of your HTML:
Using an embedded style is only an option if your ESP moves embedded styles inline, or you use another premailer tool that converts embedded styles to inline styles. This is because Gmail will remove embedded CSS from the <head> of your HTML, making the fix useless in that client when applied with embedded styles. For the fix to work properly across all email clients, it’s crucial thatstyle=”display: block” is added to each affected image using inline CSS.
A WORD OF CAUTION
When choosing to include an embedded style and rely on an inline conversion tool, be aware that there are some cases where adding style=”display: block” to every image in your email is not desirable. A great example is a situation where you’ve included HTML text right next to an image, in this case an arrow:
adding display:block would cause the image to bump down to the next line:
If you frequently use HTML text combined with small images in your emails, using manual inline style might be best.
SET UP A TESTING SCHEDULE
Webmail clients are notorious for making small changes that cause HTML email rendering headaches, and with new web browsers being released on a regular basis, it’s never been more crucial to test your emails regularly. Emails most vulnerable to unexpected changes are triggered or autoresponder emails such as welcome and confirmation emails. An annual subscription to our email testing tool may be your key to avoiding potential disaster!
FOR GEEKS AND KNOW-IT-ALLS
While I’ve been practicing this fix for well over a year, I’d always wondered what caused it in the first place. Unlike many other HTML email rendering quirks, this issue isn’t caused by a particular email client’s choice of rendering engine or an isolated decision from a webmail provider. In fact, the issue seems to become more prevalent as time goes on. So what’s the deal?
Modern web browsers are using stricter DOCTYPEs, and this exposes the fact that images are inline elements by default in these DOCTYPEs. Treating images as inline elements results in the bottom of the image to be aligned with the baseline of the surrounding text. (For non-typophiles, the baseline is an imaginary line where most letters of the alphabet sit when written in a straight line.) Essentially, browsers have begun treating images like text with the assumption that they will be used alongside each other. This leaves a little bit of room underneath each image to help text and images line up properly. When you add style=”display: block” to each image, you’re telling the browser to stop treating the image like text or an inline element, and instead push the image down into the invisible ‘baseline’ space underneath as a block-level element.
This article at the Mozilla Developer Network explains the issue in much more detail, complete with lovely illustrations.