The Guide to Successful Responsive Email Development

Jarrett Widman, Senior Web Engineer at Vokal, outlines the most important considerations for responsive email development.

On the surface, email development resembles web development, but it actually has rules all its own. The tools and methods required to develop responsive emails are most easily understood in relation to modern web development. So, let's take a look at what web developers and designers need to know to create responsive emails.

Support 15 Years of Mail Clients

Compared to the range of web browsers in common use, the range of email clients in use is staggering and amazingly inconsistent in their behavior. The push to standardization that has been a guiding light on the web for 10+ years is barely a glimmer in the world of email. Recent versions of Outlook, for example, in many cases do a worse job of rendering emails than versions of Outlook that are 10 years older.

Litmus is a service that takes screenshots of an email draft in a range of selected clients. One of the first things we do at Vokal when starting an email engagement is send email clients the list of targets we will validate against using Litmus and an explanation of how to review those results. We target a large number of clients in Litmus, going all the way back to Outlook 2000 and up to the most recent versions of iOS. We avoid some clients that are on their way out or have fundamentally bad email experiences (sorry old Blackberry users).

Just like with websites, we focus on the best experience across clients with graceful degradation where needed. Web fonts are a good example of something that adds style in newer clients, but degrades easily with CSS font-family cascades.

Avoid Unsupported Features

A bunch of stuff simply doesn't work reliably in emails. The big three that come up all the time are JavaScript, multimedia, and form elements.

JavaScript has essentially no support, so just don't use it.

Multimedia, including any mp4 video player, YouTube, and any audio player, has very poor email support. Some clients do support mp4 videos, but there should always be a fallback, and fitting a fallback in is not simple. Think of video as a way to possibly enhance emails, not a reliable way to share media with recipients. Animated gifs have pretty good support if animation is an important feature.

Form elements often trigger phishing/spam filters and generally don't work within emails, so try to avoid them. There also isn't a very good way for them to degrade on clients where they don't work.

Make Images Reliable

Images don't reliably load by default, so alt text is important for describing what an image shows, but should also be styled using properties like font-size, font-weight, and color. The img tag works well with a style attribute for alt text across clients.

Some email clients, mainly Outlook, will not scale images unless you use the height or width attributes on the img tag, as opposed to just setting the height or width in the style attribute. When inlining, Juice can automatically apply CSS height/width to img height and width attributes to make things easier. More about Juice below.

Background images are not reliable—sometimes there is no good replacement for them, but if you use a background image, make sure everything still looks ok if it doesn't load. In some cases, it's better to just flatten the background image with whatever is in the foreground to a single img.

Don't attach images to the email or inline them into HTML. These methods don't render reliably, so all images need to be hosted on a web server and linked to with absolute URLs.

Styles and CSS

Fortunately, most commonly used CSS styles work well within emails. There are a few important things to avoid, like absolute positioning and margins, but even CSS transitions work in some clients and degrade gracefully. The big gotcha with CSS in emails is that all of the styles need to be inlined into the HTML. Vokal has made some significant contributions to Juice, which is a popular CSS inliner. Anyone can install Juice from npm and inline their CSS using Grunt or other command line tools.

Because any styles not within a media query will be inlined, all media query styles have to use !important to override those inlined styles.

Yahoo has what can generously be called a quirk where it applies all media query styles to the desktop styling unless the selector starts with an attribute selector. The simple fix for this is to start all media query styles with body[style] assuming the body tag in the email will actually have a style attribute. When authoring in LESS/SASS, it is easy to just wrap the entire media query block with that parent selector and be done.

Build Your Layout with Tables

Tables are basically required for email layouts. Any typical use of div or span elements on the web needs to be planned in terms of tables. Any margin should be padding on the table or td as well. Some versions of Outlook convert some elements, like div and span to p, so its usually better to just use table or td for every block element. In addition to this, colspan and rowspan attributes will absolutely break the layout, so everything needs to be structured without those attributes. Anything that can be done with colspan and rowspan should be achievable by nesting tables.

Structuring Responsive Emails

There are several potential design issues that are easy to spot early in email designs. At Vokal, designers and developers collaborate to resolve any potential issues.

Don't overlap elements

Because margins and absolute positioning don't work reliably, anything that needs to look like it is overlapping will need to be saved to a single image. That might be ok for one-time emails, but it doesn't work as a pattern for anything where the text or images that overlap might change, such as newsletters.

Use an Appropriate Width

Desktop emails are usually viewed within an application pane or section of the browser window, making 600 to 800px a sensible width. Unless wider art or ad sizes are required, opting for a desktop width closer to 600px makes responsive design easier and pairs well with a mobile-first mentality.

Whatever is in the left column on desktop should be on the top for phones. Whatever is in the right column on desktop should be on the bottom for phones.

The above diagram shows 3 levels of nested tables. The design is such that cell A and the brighter yellow cell to its right become block elements on phone. At the same time, the blue table containing cell B does not. By nesting tables and taking advantage of this pattern, most reasonable reflows are easily achieved by making td and parent table elements display: block, and they work across all clients.

If you can't reflow the content into the right order, toggle visibility.

Is it preferable to not duplicate content in email, mostly because it increases the effort to author messages. But there are layouts where changes in flow order make is necessary to duplicate content so it can appear in different locations. Reliable visibility is verbose in email due to an odd combination of requirements in different browsers. The following example is the most concise implementation that works reliably across email clients. One thing to note is that the .mobile style doesn't actually contain display: none, which doesn't work reliably in email. The containing div is reduced to zero height and width, with overflow hidden.


<style>
  .mobile {
    float: left;
    max-height: 0;
    overflow: hidden;
    width: 0;
  }
  @media all and (max-width: 500px) {
    body[style] .mobile {
      float: none !important;
      max-height: inherit !important;
      overflow: hidden !important;
      width: auto !important;
    }
    body[style] .desk {
      display: none !important;
    }
  }
  
</style>
<body>
  <table class="desk">
    <tbody>
      <tr>
        <td>Visible on Desktop</td>
      </tr>
    </tbody>
  </table>
  <div class="mobile">
    <table class="mobile">
      <tbody>
        <tr>
          <td>Visible on Phones</td>
        </tr>
      </tbody>
    </table>
  </div>
</body>

Don't be Spam

On the web you would always use a title tag, but avoid generic titles in emails because they trigger some spam filters. If using a title, it should generally match the email subject line you'll be using.

Very large amounts of alt text triggers spam filters. This generally happens in emails where all the text are in images and someone thinks it would be a good idea to enter all the text in all the images as alt text. Most of the copy in emails should generally be in HTML text and not housed in images.

There is a whole range of other guidelines to avoid being detected as spam. It is easy to find tools online that check against a set of rules, often SpamAssasin, which is the most popular free spam filter.

Comply with the CAN-SPAM Act. You can find the basic requirements here, but in all cases you should have a physical mailing address in the footer of every email.

Go With the Flow

Emails are much more constrained in their design and functionality than web pages. Many designers and developers initially find this frustrating, but with a change of perspective you can focus on making an awesome email, rather than trying to fit a web page into an email and getting a bad result.