Fallbacks for Interactive Email: How to Combat Limited Support for Interactivity

For the third year in a row, interactive email experiences were voted one of the hottest email design trends. So why don’t we see more interactive emails in our inboxes? For many brands, limited inbox provider support is the main reason they don’t send more interactive campaigns.

You don’t have to fear limited support if you have a fallback in place. There are plenty of methods that help you create engaging, interactive emails where they are supported, while still guaranteeing a functional and beautiful experience in all other inboxes.

Why Fallbacks Matter

Support for HTML and CSS varies across email clients, and many of the HTML and CSS elements that you might use to power interactivity in email might not be supported everywhere.

If you don’t account for cases where it’s not supported, your email can look broken. Let’s look at this example of a beautiful interactive image carousel:

The interactive carousel with its powerful imagery looks great in Apple Mail, allowing subscribers to flip through the pictures using the arrows or checkboxes. But here’s how that very same email renders in Yahoo! Mail if there’s no fallback in place:

Without fallbacks, the email appears broken and likely won’t see a lot of clicks. We don’t want that to happen! So let’s look at how we can make interactive emails work everywhere with bulletproof fallbacks.

Using the power of the hide and show framework

The hide and show framework is the most basic and common tactic to set up interactivity and fallbacks in email. While simple, it’s still very powerful.

The framework does exactly what its name suggests: It hides the interactivity for clients that don’t support it and shows a fallback instead.

You set up two completely separate sections in your HTML—one for your interactive content, and one for your static fallback. That way, you can not only specify those two different types of content, but also set up different links and different tracking for each version of your email, making it possible to track and compare interactive vs. the static versions. Think of it as an A/B test within one email.

Let’s look at how you make this happen within your email code with this simplified example (or check out the CodePen):

<!-- start INTERACTIVE_SECTION -->

<!--[if (!mso)&(gte IE 10)]> <! -- -->

<div id="interactive" style="display:none; max-height:0; line-height:0; font-size:0; mso-hide:all;">

<div class="content">

This is where the Interactive Content goes.

</div>

</div>

<!--<![endif]-->

<!-- end INTERACTIVE_SECTION -->

 

<!-- start FALLBACK_SECTION -->

<div id="staticfallback">

This is where the Fallback Content goes.

</div>

<!-- end FALLBACK_SECTION -->

The interactive section uses conditional statements to hide content from email clients that don’t support interactivity. This includes MSO conditional statements that will hide everything in between them from versions of Outlook that don’t support interactivity, as well as inline CSS that visually hides content for other non-interactive email clients (that’s the code in green). Then the code highlighted in dark red pulls in styles that override the code for the interactive section while forcing the fallback section to hide instead.

We wanted to call out “visually” because the content still loads, even if it isn’t visible. This is important to note because all of the images and other files you might pull in on the interactive section will impact the loading time for the fallback layout. As a workaround, try leveraging the same images as much as possible for both layouts.

For the content, you can populate the fallback section with any conventional email code or simply wrap those <div>s around any existing static email code you might have. For the interactive section, feel free to play around with any sort of CSS-only techniques you’re interested in implementing. Searching for CSS-only carousels, hotspots, quizzes, scrolling effects, etc. can yield some great inspiration!

Utilizing externally-linked stylesheets

Meanwhile, the CSS referenced in the dark red code is hosted in an externally-linked CSS file that contains code like this:

#interactive {

display: block !important;

max-height: inherit !important;

overflow: visible !important;

}

#staticfallback {

display: none !important;

}

 

#interactive .content {

Font-family: Arial, Helvetica, sans-serif;

font-size: 20px;

line-height: 30px;

display: block;

color:#ffffff;

}

The #interactive and #staticfallback styles all have !important; rules to allow them to override the inline CSS in your HTML. These are the key style declarations that hide and show your layouts. The #interactive .content  declaration represents the code you’d use to actually style your interactive content, though interactive layouts would usually require more than this example to work. For example, if you wanted to style a CTA that only appears in the interactive layout, you would create a new declaration like #interactive .cta (or .interactive-cta, as long as the selector is unique to the interactive section) and add your styles to the CSS file.

Then you would add a link tag to your HTML referencing this external stylesheet at the very bottom of your <head> tag, like in this simplified example.

<head>

<style type="text/css">

/* Boilerplate Styles */

/* Responsive Media Query Styles */

/* Progressive Enhancement Styles */

</style>

<!-- External CSS for Interactive Version -->

<link rel="stylesheet" type="text/css" rel="noopener" target="_blank" href="">

</head>

Mastering CSS specificity

As you can tell, there’s a lot of CSS specificity trickery involved. CSS itself stands for “Cascading Style Sheets”, which refers to the order that your CSS cascades in when it comes to specificity. And specificity determines which rule is the one that wins out. Therefore, the placement of the <link> tag after all of your embedded CSS is crucial for allowing all the styles in the external CSS file to override the styles that came before it.

So why an externally-linked CSS file, instead of embedded or inline CSS? Because if an email client supports this feature, then it most likely supports all the styles contained within the external CSS file. Keeping your interactive CSS separated in this way means that you reduce the likelihood of your interactive styles conflicting with your non-interactive code, so you don’t end up with unintended results.

The icing on the cake: Optimize for limited interactive support with progressive enhancements

Once you’ve set up your two main versions—the interactive one and the static fallback—you can go ahead and enhance your static fallback version with some basic interactive elements. Here’s the static version of the email above, made more engaging using hover effects for the logo and the CTA:

You can learn how to create these simple but powerful hover effects here.

WANT MORE RESOURCES LIKE THIS?

Get the best email marketing and design tips, stats, and resources straight to your inbox and stay at the forefront of email innovation.

Stay in the know →

Alice Li

Alice Li was a Principal Email Engineer at Litmus