fallback |ˈfɔːlbak| noun

  1. an alternative plan that may be used in an emergency.
  2. a reduction or decrease.

Oxford Dictionaries

“CSS Fallbacks”1 is an email coding technique of replacing the image-based design elements: rounded corners, glow, borders, gradients and shadows with a CSS-based equivalents. The purpose of it is mainly visual — emails look very sharp and have no hairlines on high-dpi mobile screens.

Since Webkit (Everything-Apple including iOS; Android and Chrome) and Gecko (Firefox) layout rendering engines support CSS3 very well, we use their proprietary media queries to apply the CSS replacement only on them. Conceptually it looks like this:

Fig 1. Everything depends on which rendering engine the email is opened on.

Fig 1. Everything depends on which rendering engine the email is opened on.

We want the CSS Fallbacks to appear not only on smartphones, but ideally everywhere on Webkit/Gecko rendering engines, including desktop and tablets. The only condition is the particular email software has to support both media queries and the necessary CSS(3) styles.

CSS Fallbacks affect the way we code Responsive design. Old-school Responsive email is done this way (conceptually):

<head>
all media queries, activating if a screen is narrow - for mobile
</head>
<body>
Outlook-friendly table structures - for desktop
</body>

New way is (699px is arbitrary, choose the appropriate value):

<head>
@media screen and (-webkit-device-pixel-ratio), screen and (-moz-device-pixel-ratio){
  CSS Fallbacks
}
@media only screen and (max-width: 699px) {
  Responsive Styles
}
</head>
<body>
Outlook-friendly table structures
</body>

Conceptually, the old paradigm of coding Responsive email was: EITHER rigid desktop OR fluid responsive:

Fig 2. The old paradigm Responsive email coding.

Fig 2. The old paradigm Responsive email coding.

The new paradigm of coding email (Responsive or not) is building on the old foundations — adding: with fallbacks OR without:

Fig 3. The new paradigm - CSS Fallbacks and hybrid Responsive code

Fig 3. The new paradigm - CSS Fallbacks and hybrid Responsive code

See the Figure 3 above. Area 1 is the old Outlook-friendly code — your code foundation and the major headache render-testing.

Area 2 is exactly-the-same looking rigid “desktop” email, but here everything that can be replaced with CSS(3) is replaced. This is what’s shown on iPad Air, for example.

Area 3 is odd — somehow the email software supports Responsive styles but does not support enough CSS to have Fallbacks implemented reliably. It is strange one and should not happen in theory. In practice, it does, because of Windows Phone. If you put the IE Edge meta tag, you can get the email Responsive-ness working on Windows Phones:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

But with the current setup above (-webkit-device-pixel-ratio and -moz-device-pixel-ratio), CSS Fallbacks won’t activate because IE is using Trident rendering engine.

Area 4 is the wonderland — email software that supports media queries and CSS3 — for example, native Mail app on a modern iPhone. Here email looks at its best, on all screen sizes.

To recap, we take the CSS Fallbacks away from the viewport width-driven Responsive media queries (if any replacement was happening at the first place) and activate them before. We don’t want to mix Responsive media queries and CSS Fallbacks.

The Benefits of CSS Fallbacks

There are many benefits of using CSS3 fallbacks:

  • CSS styles are just a few lines of code in the <head> area, so they don’t take much space at all. The extra email file size caused by CSS Fallbacks is negligible.

  • CSS styles look perfect on ALL screens, including when zoomed-in to a maximum. They are always sharp. Just like system text.

  • The code for CSS3 fallbacks can be copied straight from Photoshop, with condition that designers have produced the PSD correctly.

  • CSS fallbacks help to counter Webkit hairlines — tiny lines appearing between table cells, appearing on Androids and iOS devices. No decorative content divided among the table cells — no hairlines!

The only drawbacks I can think of are: slightly increased code complexity and slightly increased production time.

The split of the common classes

This conceptual split in media queries will require cloning and separating all the common styles, which are used in both Responsive media queries and CSS Fallbacks. For example, you’ll need two separate classes “hide”.

Here’s why.

Imagine a responsive email newsletter, which has a sidebar that is hidden on narrow screens (hides on <599px wide). But there are also CSS Fallbacks, which need to hide some table cells with some glow effect, made of image slices. Fallbacks will call the “hide” CSS style class everywhere, including at 600px-wide viewport. If we shared the “hide” class, Fallbacks would activate the hiding of the sidebar at 600px width (and everywhere else).

Personally, I name the hide classes .h1 and .h2 keeping the correct order: first fallbacks, second responsive styles. You will need to “split” all the common CSS classes. It might be wise to keep the old classes (such as in my case, .h) to support legacy template code.

Technical considerations

The main principle is to set the CSS Fallbacks on a DIV, separate from the table structures that Outlook sees. Never hook the CSS Fallback classes on the table structures:

This is a good code example below — class="rounded_edge" is on DIV:

<table width="100" border="0" cellpadding="0" cellspacing="0">
    <tr>
        <td>
            <div class="rounded_edge">
            <table width="100" border="0" cellpadding="0" cellspacing="0">
                <tr>
                    <td align="left">
                        <img src="images/spacer.gif" width="10" height="10" border="0" style="display:block;" alt="">
                    </td>
                </tr>
                ...
            </table>
            </div>
        </td>
    </tr>
</table>

Below is a bad code example — class="rounded_edge" is on the second table:

<table width="100" border="0" cellpadding="0" cellspacing="0">
    <tr>
        <td>
            <table class="rounded_edge" width="100" border="0" cellpadding="0" cellspacing="0">
                <tr>
                    <td align="left">
                        <img src="images/spacer.gif" width="10" height="10" border="0" style="display:block;" alt="">
                    </td>
                </tr>
                ...
            </table>
        </td>
    </tr>
</table>

If you do hook classes onto the table structures, you risk that CSS Fallbacks won’t work on some versions of Android (but they’ll work on iOS).

The idea is very simple — attach the fallbacks onto a DIV, and place that DIV in a well-nested table structure. You want the DIV to be a single child of its parent TD. That’s very important. For example:

Below is a good code example — the fallbacks’ DIV is the only child of its parent TD:

<table width="600" border="0" cellpadding="0" cellspacing="0">
    <tr>
    ...
    </tr>
    <tr>
        <td><!--DIV is the only child of this TD-->
            <div class="glow">
                <table width="600" border="0" cellpadding="0" cellspacing="0">
                    <tr>
                        <td>
                            <table>...</table>
                        </td>
                    </tr>
                </table>
            </div>
        </td>
    </tr>
    <tr>
    ...
    </tr>
</table>

Below is a bad code example — there’s a table at the same level as the fallbacks DIV:

<table width="600" border="0" cellpadding="0" cellspacing="0">
    <tr>
    ...
    </tr>
    <tr>
        <td>
            <!--take this table out of here-->
            <table width="600" border="0" cellpadding="0" cellspacing="0">
                <tr>
                    <td>
                        Title
                    </td>
                </tr>
            </table>
            <div class="glow">
                <table width="600" border="0" cellpadding="0" cellspacing="0">
                    <tr>
                        <td>
                            <table>...</table>
                        </td>
                    </tr>
                </table>
            </div>
        </td>
    </tr>
    <tr>
    ...
    </tr>
</table>

If you follow the advice above, you will avoid majority (if not all) possible rendering issues related to CSS Fallbacks.

The Impact on Email Production

It’s a fact — CSS Fallbacks require an extra code to implement and slightly increase the complexity of the HTML code. But they also make email decorative elements look perfectly sharp, no matter the zoom level and without hairlines.

For me, templates with CSS Fallbacks take just as long to code and the ones without. Even before the CSS Fallbacks, I used to take care and plan the email code structures accordingly to prevent the hairlines. All that time is now substituted with implementing CSS Fallbacks.

In practice, CSS Fallbacks are easy to code because they are based on pure CSS code, and they don’t need any code hacks or special considerations. It’s like coding websites.

Another tip, you can copy-paste the CSS straight from Photoshop.

So it is CSS3 that gave us the CSS Fallbacks?

Yes and no. The majority of common style replacements are relying on CSS3 specification and were unavailable in CSS2, for example, glow (box-shadow), rounded corners (border-radius) and others. However, you can make use of an old CSS level 1 styles too. For example, you can replace the table cell-based borders with pure CSS border — CSS1 style.

Conclusion

CSS Fallbacks are a natural evolution of a modern email and slightly change the way how we code email, Responsive or not. I hope I convinced you the CSS Fallbacks is a superior email coding technique and a way to go forward. It is also a standard service I offer to my clients and the feedback is very positive. High-quality email newsletters show customers the company’s service will be high-quality too.


  1. “Fallbacks” is more appropriate term than “replacement” because of the “fallbacks” mean strictly reduction while “replacement” can mean change in any direction. CSS fallbacks reduce the table cell clutter and decrease the amount of elements that are driving the email’s design. [return]