Playing Nice in the Inbox

Coding email can be a tricky business. Once you get the basic rules down, it’s smooth sailing — until you encounter some bugs.

As we all know, bugs are par for the course in web development — but email introduces a few additional complexities.

Not only will your recipients use different browsers, but you’ll also have to contend with a variety of email providers, devices and apps — and all of these will render your email code (which you’ve worked so hard to translate from design to inbox) in myriad ways.

It’s best to become familiar with each and every one of the canvases (and their many quirks) your users will use to view your messages on, and play nice in the inbox. Below are a few of the most common bugs I have come across over the years, and solutions to fix them.

Gmail, Yahoo and iOS got the blues

Remember when web pages consisted mostly of black text and white backgrounds, with the occasional word underlined in blue text? Readers caught on to the fact that blue signified “hyperlink,” and learned where to click.

Most web designers aren’t still partying like it’s 1999, and will override that default blue with a hex value that compliments their personal design and color palette.

Unfortunately, emails viewed in Yahoo and Gmail are a little stubborn about letting go of that penchant for blue links. Simply defining a new hex value as a style within an <a> tag just won’t cut it on these platforms. The easiest solution is to add an additional <span> tag, nested inside the <a> tag, defining the hex value a second time.

<a href="http://www.gilt.com/" target="_blank" style="color:#c98702;">
  <span style="color:#c98702">
    Act Now
  </span>
</a>

Gmail doesn’t see the world in black and white. When using a hex value of #FFFFFF or #000000, or defining a link color as either “black” or “white,” Gmail will still default to blue for these values no matter how many ways you define them — in the <a> tag, in an additional <span> tag, etc.

To override blue links in pure black or white text, I replace the text color with a hex value one character off from the standard black and white — i.e. #FFFFF1 or #000001 — and define it in both the <a> tag and additional <span> tag. The difference is subtle enough to pass as black or white to the human eye, and Gmail will honor your color choices.

In a similar vein, iOS automatically turns phone numbers, addresses and dates into blue hyperlinks even if you haven’t added an <a> tag.

Why does it do this? Possibly because it assumes that you’ll want to call, map or add these blocks of text to your calendar. To avoid unwanted/surprise links, again wrap any phone numbers, addresses and other “vulnerable” content with a <span> and manually style it to the color of your choice.

iOS supports topline CSS and media queries, so if you have a lot of addresses, phone numbers or dates in your email, you can define the color once and add the class throughout your code.

Outlook and Gmail ❤ whitespace

Image maps are not widely supported across email clients, so a best practice is to slice images. Note that Outlook and Gmail both add white space around images, which produce a gap-like effect that can cause some aggravation whenever images need to be tightly stacked or flushed.

Thankfully, adding a display:block style to each image will eliminate the extra white space.

<img src="image.jpg" border="0" style="display:block">

Gmail App on Android brings its own width to the table

From time to time, Android will set its own width for cells in a table when viewing the email on the Gmail app. I’ve noticed this in nested tables with two or more columns — one column gets all the love and the greater width, while the other is left in a skinny, narrow cell.

Here’s a workaround:

• If the cell contains an image of equal width, add a min-width value to the cell.
• If the cell doesn’t contain elements that make up the fully intended width, add a transparent GIF as the first line of code in the cell, and set the width in the image tag to the desired cell width (yes, coding like it’s 1999). This, in addition to appending the min-width value to the cell, should force it to expand to contain the image and ensure your cells render at the correct width.

<table width="650" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#f7fcff">
  <tr> 
    <td width="240" valign="top" style="background-color:#E4E3DD; min-width:240px;">
      <a href="http://www.gilt.com/?%%=v(@tracking_parameters)=%%CRM20_M" target="_blank" alias="BODY - Main Image"><img src="http://cdn.gilt.com/email/images/1073080926_CRM_DedicatedEmail_M_v3_summer2_1.jpg" width="240" alt="20% Off on Gilt.com" border="0" style="display:block;" /></a>
    </td> 
    <td width="410" valign="top" style="background-color:#f7fcff; min-width:410px;">
      <img src='spacer.gif' width='410' height='1' border='0'>
    </td>
...

iOS creates its own borders

I’ve noticed that this bug occurs whenever a background color or image is applied to rows within a table. iOS inherits the background color, which shows up on the outside of the table as borders then disappears as you zoom in to view it at close range.

My workaround: Add an extra wrapping table with the parent background color defined and nest the table and the cells which contain the background color that formerly showed through inside of this, to ensure the entire table gets the intended color assigned to it.

<table width="645" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#ffffff;">
  <tr>
    <td width="645" style="background-color:#FFFFFF; padding-top:15px;">
      <table width="645" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#454441;">
        <tr> 
          <td width="645" style="padding-left:11px; background image:url(http://cdn.gilt.com/email/images/1326817406_hero_overlay.jpg); background-repeat:no-repeat; background-color:#454441;"> 
          </td>
        </tr>
      </table>
    </td>
  </tr>
  <tr>
    <td width="645" valign="top" style="padding-bottom:15px;background-color:#ffffff;">
      <a href="#" target="_blank" alias="Image - Top Picks Hero">
        <img src="http://cdn.gilt.com/email/images/626159401_hero.jpg" width="645" height="260" border="0" style="display:block;" />
      </a>
    </td>
  </tr>
</table>

Hopefully these suggested bug fixes keep you from banging your head against the wall. Rest assured that more bugs will present themselves as email clients and apps continue to evolve.

Remember that it’s always important to test, test, test — on your favorite devices, in multiple email clients, and in rendering tools like ReturnPath and Litmus. Also remember that it doesn’t hurt to share your own solutions — your peers will thank you when it’s their turn to discover the latest bug.