Mastering Responsive Web Design with HTML5 and CSS3 (2015)

Chapter 8. Responsive E-mails

Here we are, after traveling back in time. Think of the late 90s and designing with tables; oh yes, you read right, designing with tables.

Today, things are not any different when it comes to creating e-mails: we have to use tables for layout. Why? It's simple. There aren't any wars. E-mail client wars, that is.

Unlike the browser wars of 1995, where Netscape and Internet Explorer battled for market supremacy, e-mail clients have been living their own separate lives practically oblivious to each other since anyone can remember.

Thanks to the browser wars, we now have such awesome standard-compliant browsers that are full of features, customization capabilities, constant updates, and so on, making everyone's online life a bit easier.

E-mail clients, on the other hand, evolve at their own pace and that pace is slow because there really isn't any competition. Moreover, the vast majority of corporations are already locked in with Microsoft's Outlook. In the more recent versions of Office, Outlook has actually become worse than its earlier counterparts, thus not really helping the e-mail landscape improve in support of more modern technologies.

To top this off, there are e-mail clients that are relatively new and radically reject support for the <style> element or even media queries altogether.

But e-mail is an incredibly efficient and formidable marketing tool that—regardless of the level of technology—we need to be prepared to work with soon or later.

In other words, e-mail as a medium of communication is not going anywhere any time soon, and we as web designers/developers have to design e-mails with tables and inline styles.

But don't worry, I will show you that with the basic principles of RWD, a little bit of common sense using progressive enhancement, and by always trying to keep things simple, designing and implementing responsive e-mails is not difficult and can be fun.

In this chapter, we're going to talk about the following topics:

· Why do we need to worry about responsive e-mails?

· Don't overlook your analytics.

· Things to consider for responsive e-mails.

· Responsive e-mail build.

· Third-party services.

Why do we need to worry about responsive e-mails?

The main reason we need to worry about responsive e-mails is simple: about 65 percent of e-mails are opened on mobile devices (smartphones and tablets). The remaining 35 percent of e-mails are opened on desktop. Additionally, responsive e-mails have more engagement than nonresponsive ones.

In addition to this, e-mails opened in desktop have more engagement than e-mails opened on mobile devices.

Check out the following articles:

· Nearly 65% of e-mails in the U.S. are opened on mobile devices: https://www.internetretailer.com/2014/01/23/nearly-65-e-mails-us-are-opened-mobile-devices

· 65% of marketing e-mails were opened on a mobile device last quarter; Android tablet use doubles: http://www.phonearena.com/news/65-of-marketing-emails-were-opened-on-a-mobile-device-last-quarter-Android-tablet-use-doubles_id51864

Tip

The term engagement means that the user clicks/taps. So, more engagement simply means more clicks/taps.

Don't overlook your analytics

Before starting to push pixels, nest tables, and style elements, it's absolutely imperative that we look at the analytics and have a bird's eye view of the landscape we're going to create e-mails for.

Doing this will allow us to understand:

· When are our e-mails being opened.

· Which days have more opens.

· Which hours have more opens.

· Whether the season is causing more/less openings.

· Which devices are being used to open our e-mails.

· What e-mail clients are being most used/less used.

If, for example, the analytics have data stating that Outlook 2013 is rarely used (wouldn't that be awesome), then we may not need to worry about this e-mail client at all.

If the Yahoo Mail app in Android is the most commonly used application and platform, then we can safely use more advanced CSS properties and progressively enhance, knowing that our ideas will display correctly.

Doing market share research is important, but your own analytics are ultimately the ones that will dictate how you're going to approach your e-mail development strategy.

Recommendations for building better responsive e-mails

Although some e-mail clients are getting better at rendering e-mails, there are other e-mail clients that are not really as good as they should be. This means that we need to build something basic and progressively enhance it for better e-mail clients.

There are a few guidelines that are important to consider when building responsive e-mails:

· Define the e-mail client with the least CSS and HTML support: Knowing which e-mail client has the least HTML and CSS support will save us unnecessary headaches and time during testing. Again, this is where analytics are crucial.

· Use progressive enhancement: First, design and build for the e-mail client that has the least CSS and HTML support. Then, we enhance the design and experience using that core base.

· Stay within a width of 550px to 600px: This is very important because most e-mail clients have very narrow preview panes. Moreover, 600px or less will look good on desktop clients and web browsers, and the e-mail will remain readable when scaled down or turned responsive on small screens.

· Use tables for layout: Most e-mail clients have nowhere near the same support for HTML and CSS as web browsers, so building layouts with tables is still the way to create e-mails.

· Inline CSS: Many e-mail clients remove the <head> section of the e-mail, thus anything we put there will be stripped out. So, we need to inline the CSS in order to achieve the necessary styling.

· Use system fonts: Although using web fonts is technically possible, it's best to stick to system fonts so the e-mails look as similar as possible across different devices and different e-mail clients. However, if you do decide to use web fonts, go for it and always use them as part of the progressive enhancement process.

· Provide a fallback color for background images: Using background images isn't really that difficult. Outlook is the only client that requires special markup (Conditional Comments) to make it work. However, always provide a fallback background color in case the image doesn't load.

· Always use the alt attribute on images: If images do not load or load too slowly, the e-mail client will show the alternate text. Make sure you put something descriptive in the alt attribute as well. Instead of Logo, something like Company Logo - Tagline would be ideal.

· No need to do mobile-first: Because we're doing progressive enhancement, we are starting with the e-mail client with the least support for HTML and CSS. Hence, this e-mail client very likely doesn't support media queries or the viewport meta tag. So a mobile-first approach may not be necessarily the best option, at least yet.

· Use the HTML5 DOCTYPE: We could certainly use the old HTML4 DOCTYPE, but we can use the HTML5 DOCTYPE as well which is always a good measure.

· Avoid using HTML5 elements: Although we can use the HTML5 DOCTYPE, support for HTML5 elements is practically nonexistent. So avoid using HTML5 elements in e-mails.

· Keep it simple: Most e-mails have a very short lifespan, so making an intricate layout is not really necessary. Create a simple, one-column layout and this will save us a lot of headaches. Focus strongly on the design itself. This is where a solid typographic Modular Scale can work wonders.

Responsive e-mail build

Defining the features of the e-mail is also part of the build, so let's define those:

1. Create a Modular Scale for typography.

2. Create two designs to help visualize the e-mail beforehand: one for large screens and one for small screens.

3. The e-mail will have a maximum width of 600px and minimum width of 320px.

4. Use progressive enhancement.

Modular Scale for typography

To build our Modular Scale, we're going to use the following values:

· Base one (16px): Which is our base font size.

· Base two (600px): Which is the maximum width of our e-mail.

· Ratio (1.618): The Golden ratio.

This Modular Scale can be found at http://www.modularscale.com/?16,600&px&1.618&web&table.

Modular Scale for typography

Design – large and small screen views

The following designs will help get a better picture of the e-mail on large and small screens. This is how it looks at 600px wide:

Design – large and small screen views

This is how the e-mail looks at its smallest size, 320px wide:

Design – large and small screen views

Let's get right down to business and build a responsive e-mail.

Setting up a basic HTML template

Let's start with the most basic template. Then, we're going to add to it the different things we need to have a sound template.

Here's the first take on the HTML with a few initial elements in the <head> section:

· Define the language of our document with the lang attribute, English in our case.

· Since our design has a colored background, we need to give the <html> and <body> elements a height of 100 percent. This makes both elements stretch to the full height of the viewport. Otherwise, the background will end where the bottom of the e-mail is and then the page will show a white background.

· Add a <title> tag.

· Add the following meta tags:

· Character set UTF-8

· Viewport

· Make Internet Explorer use the latest rendering engine possible

· Remove the autostyling of phone numbers in OSX/iOS

· Who says we can't use the web fonts? Only a handful of e-mail clients support them, those that don't will just fallback to a system font in our font stack, very likely Arial or Helvetica. Let's use Roboto.

Here's the HTML:

<!DOCTYPE html>

<head>

<title>Mastering RWD with HTML5 and CSS3</title>

<meta charset="utf-8">

<meta name="viewport" content="width=device-width, initial-scale=1.0">

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

<meta name="format-detection" content="telephone=no">

<link href='http://fonts.googleapis.com/css?family=Roboto:300,500' rel='stylesheet'>

</head>

<body style="height: 100%;">

</body>

</html>

Using CSS reset to normalize display

Let's add the necessary CSS reset styles that will help keep a relatively uniform display across as many e-mail clients as possible.

The following list outlines what exactly we'll reset (also called normalizing) across several e-mail clients:

· Outlook (all versions):

· Force it to provide a View in browser link.

· Make it maintain any custom line heights defined.

· Remove spaces on left- and right-hand side of <table> elements.

· Fix the padding issues.

· OSX/iOS/Windows Mobile:

· Fix automatic increase of font size to 13px when fonts are small.

· Yahoo:

· Fix the paragraph issues.

· IE:

· Fix the resized images issue.

· Hotmail/Outlook.com:

· Make it display e-mails at full width.

· Force it to display normal line spacing.

· All e-mail clients:

· Remove the border around linked images.

Here's the embedded CSS:

<!DOCTYPE html>

<head>

<title>Mastering RWD with HTML5 and CSS3</title>

<style>

/*Force Outlook to provide a "View in Browser" link.*/

#outlook a { padding: 0; }

body {

width: 100% !important;

margin: 0;

padding: 0;

/*Outlook: Make Outlook maintain any custom line heights defined.*/

/*OSX/iOS/Windows Mobile: Fix automatic increasing of font size to 13px when fonts are small.*/

-webkit-text-size-adjust: 100%;

-ms-text-size-adjust: 100%;

}

/*Yahoo: Fix paragraph issue*/

p { margin: 1em 0; }

/*Outlook: Remove spaces on left and right side of a table elements.*/

table {

}

/*Outlook 07, 10: Fix padding issue.*/

table td { border-collapse: collapse; }

img {

outline: none;

text-decoration: none;

/*IE: Make resized images look fine.*/

-ms-interpolation-mode: bicubic;

}

/*Remove border around linked images.*/

a img { border: none; }

/*Prevent Webkit and Windows Mobile platforms from changing default font sizes, while not breaking desktop design.*/

/*Force Hotmail to display e-mails at full width.*/

.ExternalClass{ width:100%; }

/*Force Hotmail to display normal line spacing.*/

.ExternalClass,

.ExternalClass p,

.ExternalClass span,

.ExternalClass font,

.ExternalClass td,

.ExternalClass div {

line-height: 100%;

}

</style>

</head>

</body>

</html>

With this basic template in place, let's start adding the content.

Adding the e-mail content

Building e-mails is pretty much a you gotta do what you gotta do! mentality. In other words, we do whatever we have to do to make things display as we want them to. Sometimes, we have to use nonbreaking spaces ( ) to separate things out, use the <br> tags to make things go to the next line, even use several <br> tags to create spaces between elements.

However, this does not mean that we're just going to throw all the good things we've learned out the window, no way.

Let's keep things as clean and lean as possible, nesting where necessary, and adding the necessary styles where required.

Tip

To optimize space and help focus on the important parts, we're going to work with the markup inside the <body> tag only.

Creating a 100 percent wide wrapping table

This is our outermost table container and it's always a good practice to have one. This table will allow us to handle any padding we want or need in our design, because adding padding on the <body> tag may not be a reliable approach.

We can also use this outer table to add a background color if our design has one. We're going to give this outer table a width and height of 100 percent.

We're also adding 20px padding in the cells; this will give the whole e-mail a bit of room to breathe, because it won't be touching the top and bottom edges of the viewport/panel it's going to be seen in. The code is as follows:

<table width="100%" height="100%" cellpadding="20" cellspacing="0" border="0" bgcolor="#efefef" class="outer-container-table">

<tr>

<td class="center"> </td>

</tr>

</table>

</body>

Tip

I'm adding classes to some elements in the e-mail that I may not necessarily use right away. I'm adding them anyway in case in the future something changes, I already have those classes in place and can edit faster.

Creating the 600px inner table

We're declaring the width of this inner table with the HTML attribute width, rather than a width within an inline style. We're also adding a white background to this table so that our content sits over it and blocks the light gray background from the wide container.

The 1px border can be added using the border shorthand. Some say don't use CSS shorthands in e-mails! However, after testing several e-mail clients, the shorthand works just fine.

Adding a 10px margin at the top will help give the e-mail a bit more room. The code is as follows:

<tr>

<table width="600" cellpadding="0" cellspacing="0" border="0" bgcolor="white" class="center" class="inner-container-table" style="margin-top: 10px; border: #999999 1px solid;">

<tr>

<td></td>

</tr>

</table>

</td>

</tr>

</table>

</body>

Notice how I used the term white for the background color on the .inner-container-table? That's because I want to show you that you can also use HTML color names instead of hexadecimal values. All e-mail clients support this feature. It's also more descriptive.

There are plenty of resources out in the open Web listing all the HTML color names, but I like this one in particular because it groups the color names by categories. So, it is easier to use in a design: http://html-color-codes.info/color-names/.

Adding the header image

Inside the empty <td> element all we need to do is add the <img> tag that calls the header image.

Images are inline-block elements by default. In order to avoid unwanted behavior, make sure the image has display: block; and width: 100%; elements as shown here:

<tr>

<tr>

<td>

<img src="https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/header-email-devices.png" alt="Mastering RWD with HTML and CSS3" style="display: block; width: 100%;">

</td>

</tr>

</table>

</td>

</tr>

</table>

</body>

Creating the content wrapping table and all its content

This is where most of the magic happens because we are now creating the body of the e-mail, including the footer. A few things to note:

· The width of the first table is 88 percent. I did this to show you that you can be arbitrary if you want to. Moreover, you don't have to use pixels every time and you can also use other values different than 100 percent when using percentages.

· In some parts, I'm liberally using the <br> tags. This is because the spacing between some elements is where I wanted them to be. Under other circumstances, this would be a pretty bad practice; in e-mail, doing this is quite useful and very common.

· We're going to use three rows: one for the main header, one for the body, and one for the Call to Action (CTA) button. Doing this will allow us to handle each section independently, without having to worry about affecting the other two when debugging or styling.

· The footer will be separated from the main content structure, so we can handle the background image easily.

The markup is as follows:

<tr>

<tr>

<td>

</td>

</tr>

<tr>

<td class="center">

<table width="88%" cellpadding="0" cellspacing="0" border="0" class="center" class="content-table">

<tr>

<td class="center">

<table width="100%" cellpadding="10" cellspacing="0" border="0" class="center">

<tr>

<td style="font-family: Roboto, Arial, Helvetica, san-serif; font-weight: 500; font-size: 33.441px; text-align: center;"><br>Mastering RWD<br>with HTML5 and CSS3</td>

</tr>

<tr>

<td>

<h2 style="font-family: Roboto, Arial, Helvetica, san-serif; font-weight: 500; font-size: 25.888px;">Responsive Emails</h2>

<p style="font-family: Roboto, Arial, Helvetica, san-serif; font-weight: 300; font-size: 16px; line-height: 26px">And here we sare after traveling back in time: think of late 90's and designing with tables, oh yes you read right, designing with tables.</p>

<p style="font-family: Roboto, Arial, Helvetica, san-serif; font-weight: 300; font-size: 16px; line-height: 26px"> And today things are not any different when it comes to creating e-mails: we have to use tables for layout.</p>

<p style="font-family: Roboto, Arial, Helvetica, san-serif; font-weight: 300; font-size: 16px; line-height: 26px">Why? Simple. There aren't any wars. Email client wars that is… (continued).</p>

</td>

</tr>

<tr>

<td style="font-family: Roboto, Arial, Helvetica, san-serif; font-weight:300; font-size: 25.888px; text-align:center;">

<br>

<a href="#" target="_blank" style="padding: 20px 30px; border: #663300 2px solid; border-radius: 5px; text-decoration: none; color: white; background: #ff8000;" class="main-cta">Get the Book! »</a>

<br><br><br>

</td>

</tr>

</table>

</td>

</tr>

</table>

</td>

</tr>

<tr>

<td>

<table width="100%" cellpadding="0" cellspacing="0" border="0" class="footer-table-ctnr" style="background: #666666; background: linear-gradient(#333, #666);">

<tr>

<td background="https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/trianglify-black.png">

<table width="95%" class="center" cellpadding="30" cellspacing="0" border="0">

<tr>

<td style="font-family: Roboto, Arial, Helvetica, san-serif; font-weight: 300; font-size: 12px; line-height: 20px; color: white;">

<p style="margin: 0;"><span style="font-weight: 500;">Book:</span> Mastering RWD with HTML5 and CSS3</p>

<p style="margin: 0;"><span style="font-weight: 500;">Author:</span> Ricardo Zea</p>

<p style="margin: 0;"><span style="font-weight: 500;">Publisher:</span> Packt Publishing</p>

<br>

</td>

</tr>

</table>

</td>

</tr>

</table>

</td>

</tr>

</table>

</td>

</tr>

</table>

</body>

At this point, this is what the e-mail looks like:

Creating the content wrapping table and all its content

And we're done! Are we? Not yet, we still have a few things to do:

· Add the Outlook 2007/2010/2013 Conditional Comments hacks for the background in the footer and the CTA button.

· Add the media queries.

· Add the Outlook web font fallback style.

Adding the Outlook 2007/2010/2013 Conditional Comments hacks

Just like IE in the times of table-based layouts, Outlook rules the landscape of e-mail clients in the desktop. So we can't ignore this client when creating e-mails.

That's all fine and dandy; the problem is that most Outlook versions have very poor HTML rendering capabilities, so HTML hacks via Conditional Comments are (unfortunately) necessary. They are not difficult to implement; you just have to know when to implement them.

Conditional Comments are most useful for background images and large CTA buttons. In our example, we have both: the black/gray triangles background pattern in the footer and the orange Get the Book » CTA that is Call To Action.

In the following markup, you'll be able to note the following points:

· The Conditional Comments wrap only the element in case. In other words, ensure that you don't wrap more elements than required, otherwise, we'll be creating more problems than solutions.

· Both the footer and the CTA buttons require us to edit things in two places: the element itself and inside the Conditional Comments.

· E-mail Conditional Comments look quite obscure; they don't adhere to any standards, since they are proprietary technology. Consider them more like a patch than part of progressive enhancement. They are a flat-out hack.

· Editing Conditional Comments isn't too difficult. The parts that are customizable are either inline CSS properties/values, or a src attribute for images—nothing we haven't seen before.

Tip

For the purpose of clarity and to cover the scope of this book, I'm going to show you only the two sections that are wrapped in Conditional Comments.

Conditional Comments for the background image in the footer

This is how the HTML looks:

<!--[if gte mso 9]>

<v:rect xmlns:v="urn:schemas-microsoft-com:vml" strokecolor="none" style="width: 600px; height: 184px;">

<v:fill type="frame" src="https://s3-us-west-2.amazonaws.com/s.cdpn.io/9988/trianglify-black.png"></v:fill>

</v:rect>

<v:shape style="position: absolute; width: 600px; height: 184px;">

<![endif]-->

<tr>

<p style="margin: 0;"><span style="font-weight: 500;">Book:</span> Mastering RWD with HTML5 and CSS3</p>

<p style="margin: 0;"><span style="font-weight: 500;">Author:</span> Ricardo Zea</p>

<p style="margin: 0;"><span style="font-weight: 500;">Publisher:</span> Packt Publishing</p>

<br>

</td>

</tr>

</table>

<!--[if gte mso 9]>

</v:shape>

<![endif]-->

</td>

Conditional Comments for the CTA buttons

The following snippet was adapted from Eli Dickinson's post How to make HTML e-mail buttons that rock from IndustryDive.com (http://www.industrydive.com/blog/how-to-make-html-email-buttons-that-rock/).

Here's what the markup looks like:

<br>

<!--[if mso]>

<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word" href="http:#" style="height: 60px; width: 300px; v-text-anchor: middle;" arcsize="10%" stroke="f" fillcolor="#ff8000">

<center style="color: #ffffff; font-family: Roboto, Arial, Helvetica, san-serif; font-weight:300; font-size: 25.888px;">

Get the Book! »

</center>

</v:roundrect>

<![endif]-->

<![if !mso]>

<![endif]-->

</td>

Adding media queries

The amount of code used in the media queries for this e-mail is minimal. This is the result of having a solid foundation of features before any HTML or CSS was created.

The things that made this e-mail a solid build are listed as follows:

· Setting a typographic Modular Scale.

· Keeping the layout to a single column.

· Building for the most problematic e-mail client first.

· Using progressive enhancement.

· Knowing where to apply Conditional Comments.

The media queries are simply as shown here:

/*Responsive Styles*/

@media (max-width: 380px) {

.main-cta { padding:10px 30px !important; white-space: nowrap !important; }

}

@media (max-width: 600px) {

.inner-container-table { width: 95% !important; }

.footer-table-ctnr td { padding: 10px 0 10px 5px !important; }

}

Tip

Since inline styles have higher specificity than the ones in the <style> tag, we need to add the !important declaration to the end of the values in order to override those inline styles.

Here's what we see in the media queries:

· Since we are using the desktop-first approach, we use the max-width property.

· We see a media query at 380px, because the orange CTA looks a bit thick in small screens at this width. So, we reduce the top and bottom padding from 20px to 10px.

· We also add a white-space: nowrap !important; element for good measure and avoid having the button wrap to a second line.

· Once the viewport hits 600px, we're going to make the inner-container-table 95 percent wide. This will give the e-mail a bit of padding on the sides, allowing it to breathe and not feel boxed in such a small space.

· Then, we're going to reduce the padding on the table in the footer. This helps use a bit more of the available space while keeping the credits in a single line each.

Outlook web font fallback style

Outlook won't use any of the fallback fonts in the font stack. It will just use Times New Roman and sometimes this is not what we intend.

So using a specific style within Conditional Comments to target Outlook is the way to solve this problem. This style should go after the closing the </style> tag of the main embedded style sheet.

Here's what it looks like:

<!--[if mso]>

<style>

/* Make Outlook fallback to Arial rather than Times New Roman */

h1, h2, p { font-family: Arial, sans-serif; }

</style>

<![endif]-->

And that's it! Really, it is. Here's a demo I created in CodePen: http://codepen.io/ricardozea/pen/d11a14e6f5eace07d93beb559b771263

Screenshot of various e-mail clients

This e-mail was tested on the following e-mail clients and platforms:

· Desktop:

· Outlook 2010

· Gmail

· Yahoo! Mail

· Outlook.com

· Mobile (iPhone):

· Mail App

· Gmail App (mobile-friendly view)

· Gmail App (original view)

· Yahoo Mail App

· Mobile (Android):

· Gmail App

Here's an image of the e-mail on various desktop and mobile clients:

Screenshot of various e-mail clients

Here, a few of the e-mail clients, both desktop and mobile, were actually able to pick up Roboto, the web font we used. The rest of them used Arial from the font stack, which was our plan anyway.

On desktop, surprisingly, Outlook 2010 was the only one able to render Roboto—albeit the font looks bolder than it really is—yet it still was the only one.

On mobile, iPhone's mail app and Gmail on Android were the ones that were capable of using Roboto.

Third-party services

When building responsive e-mails, we have to complement our bag of tricks, hacks, and broad understanding of e-mail clients' quirks and mishaps, with tools that can allow us to test faster, optimize our workflow, improve our efficiency with more modern technologies, and learn from others.

There are as many tools out there as there are web designers; the ones we're going to mention are strongly related to what this book is about. Also, all these tools are free. Let's take a look.

Litmus's PutsMail

I have to admit that the name of this tool isn't very descriptive and doesn't make any reference to how useful this tool is. With Litmus's PutsMail, we can send an e-mail to any account we want for testing and debugging. With the click of a single button, PutsMail sends an e-mail to virtually any number of e-mail accounts we want.

PutsMail allows us to do the following things:

· Add any e-mail(s) to send the tests to

· Add a subject line

· Paste our HTML

Once we have that in place, we just click on the button to send the e-mail and off we go to test on all devices. No need for logins and cumbersome interfaces in e-mail management platforms.

I used this tool to send the e-mails you saw in the image with all the e-mail clients' screenshots a few paragraphs back.

The advantages are:

· It's very easy to use, and has a very low learning curve.

· Unlike some e-mail management services, PutsMail sends the test e-mails right away.

· Adding and removing e-mails from the list is very easy.

· In addition to testing regular HTML e-mails, it also allows you to test plain text and Apple Watch versions.

· It has the option to inline the CSS if needed.

· The markup is neatly highlighted in the HTML field.

· It's free.

The disadvantages are:

· Sometimes you need to delete an e-mail and add it again to be able to receive the test.

· Each e-mail marketing service has different rules about what gets stripped out or what is left in the markup upon sending the e-mail. So PutsMail's rules may be different from other e-mail marketing provider's rules.

Litmus's PutsMail can be found at the following URL: https://putsmail.com/.

CSS inliners

Writing inline CSS is quite a tedious task: if our paragraphs have font-family: Arial, Helvetica, san-serif; font-style: italic; font-weight: bold; font-size: 18px;, then we have to copy and paste all these attributes into each paragraph. Alternatively, we have to copy and paste the same paragraph and change the text inside of them.

Don't even think about using the font shorthand. What about a change in one of the properties? Well, we now have to make the change in every paragraph. Doing a find-and-replace can be risky, which means more time testing. Enter CSS inliners!

With CSS inliners, we can write our CSS inside a <style> tag in the <head> section of the e-mail template, just like we would do when creating a normal web page. Once we're done, we upload the e-mail template into the CSS inliner tool. The tool will inline the CSS automatically in each corresponding HTML tag.

So if we have the following paragraph:

<p class="note__important">CSS inliners are an awesome tool!</p>

Then, we write this in the <style> tag in the <head> section:

<style>

p.note__important {

font-family: Arial, Helvetica, san-serif;

font-style: italic;

font-weight: bold;

font-size: 18px;

}

</style>

The CSS inliner will do this:

<p class="note__important" style="font-family: Arial, Helvetica, san-serif;font-style: italic;font-weight: bold;font-size: 18px;" >CSS inliners are an awesome tool!</p>

The advantages are as follows:

· We can include all our styles in a <style> tag in the <head> section of the e-mail template, just like in a regular web page build.

· It's simple to use CSS inliners: paste your markup, press the inline button, and you're done.

· It leads to considerable reduction in repetitive tasks, since placing a class in the <style> tag is all we need to do—the tool does the rest.

· Most CSS inliners are free.

The disadvantages are as follows:

· Testing e-mails is very time consuming, so using a CSS inliner to create test e-mails adds an extra step to the process.

An exception to this is Litmus's PutsMail, since it has the option to inline the CSS upon sending the test e-mail.

· CSS inliners have different ways of writing the styles: some add spaces after the semicolon while others don't. This may or may not concur with one's style.

Some of the most popular CSS inliners are as follows:

· MailChimp (http://templates.mailchimp.com/resources/inline-css/)

· Campaign Monitor (http://inliner.cm/)

· Dialect's Premailer (http://premailer.dialect.ca/)

· Zurb's Inliner (http://zurb.com/ink/inliner.php)

Advanced e-mail frameworks

Who says we can't build e-mails with modern and more advanced technologies, such as Sass, Grunt, and Node.js?

For those who are a bit more technical and love frontend development, these e-mail frameworks can speed things up tremendously.

The advantages are as follows:

· These technologies boost the speed of the development and testing phases.

· These technologies run locally on one's machine; this means that everything executes much faster than using a third-party, web-based service.

· If you're a frontend developer who is familiar with such technologies, learning to use any e-mail framework can be much easier.

· Some e-mail frameworks allow us to reuse components, similar to using includes, like the header and footer, and so on.

· Creating plain text e-mails is an option in some e-mail frameworks.

· Any time any of us uses an open source project, we are helping a fellow web professional in their career, and any community around such projects, making a better web.

· There is support from the developer(s) and the ecosystem of contributors of the project.

· These technologies are free.

The disadvantages are as follows:

· The learning curve can be steep if one is not familiar with such frontend technologies.

· It requires knowing and understanding more than one frontend technology beforehand.

Some of the e-mail frameworks are as follows:

· Nathan Rambeck's Email Lab (https://github.com/sparkbox/email-lab) It uses the following:

· Node.js

· Grunt

· Bundler

· Sass

· Ruby

· Premailer

· Nodemailer

· Handlebars/Assemble

· Alex Ilhan's Zenith (https://github.com/Omgitsonlyalex/ZenithFramework)

You can find a tutorial in Litmus at https://litmus.com/community/learning/23-getting-started-with-sass-in-email. It uses the following:

· Sass

· Compass

· Premailer

· Lee Munroe's Grunt Email Workflow (https://github.com/leemunroe/grunt-email-workflow)

It uses the following:

· Grunt

· Ruby

· Node.js

· Sass

· Premailer

· Mailgun (optional)

· Litmus (optional)

· Rackspace Cloud (optional)

Responsive e-mail template services

I've always believed that being hands-on is the best way to learn. However, in the world of e-mail, being hands-on means spending a lot of time working with HTML and CSS in ways that are no longer a good practice. Using tables for layout (not that using floats is any better), inlining CSS, dealing with quirky e-mail clients, and so on, takes a lot longer than necessary for testing and debugging, and all that other good stuff.

A way to speed things up is to use third-party e-mail templates because the authors have already, at least for the most part, done the dirty work for us. Let's take a look at the pros and cons of using third-party responsive e-mail templates.

The advantages are:

· It's likely that thorough testing has already been done; this reduces our own testing time tremendously.

· If we are happy with the layout, all we need to do is replace the content with our own.

· Some e-mail template services even allow you to send the e-mail itself after editing it.

· Some services don't require the author to know any HTML or CSS in order to create a responsive e-mail.

· Downloading the e-mail template is an option provided by some e-mail template services.

· Most responsive e-mail templates for download are free.

· Some paid drag-and-drop e-mail building services offer a free account with a lot of functionalities available with their free plan.

The disadvantages are:

· Although minimal, some testing of our own is still necessary.

· If we want to make changes to the layout, sometimes it's not possible. This depends on the e-mail template service.

· Although some e-mail template services allow us to send the e-mail, they don't provide any analytics or backend where we can see how the e-mail performed.

· Image optimization may or may not be ideal. There's no way to know.

· Reusing an old e-mail template is not possible with some services, so we have to edit everything again from scratch if we plan to use the same layout.

Some of the most common responsive e-mail templates for download are as follows:

· MailChimp's Email Blueprints (https://github.com/mailchimp/Email-Blueprints)

· Zurb Ink (http://zurb.com/ink/templates.php)

· Litmus's Slate (https://litmus.com/resources/free-responsive-email-templates)

· Brian Graves's Responsive Email Patterns (http://responsiveemailpatterns.com/)

The following are drag-and-drop e-mail building services:

· Stamplia Builder (https://builder.stamplia.com/)

· MailUp's BEE Free (https://beefree.io/)

BEE is an acronym for Best E-mail Editor

See how an e-mail was built

This tool has got to be one of the most amazing and useful tools for e-mail development and learning. Litmus's Scope bookmarklet allows us to see, from within any webmail client, how an e-mail template was built.

Tip

A bookmarklet is a JavaScript component that you store in your bookmarks, usually your bookmarks bar. When you click on the bookmarklet, a special functionality displays. A bookmarklet is not a bookmark per se; it happens to be stored with the bookmarks, but offers a very different functionality than a regular bookmark.

The way Scope works is quite simple:

1. Go to the Scope site: https://litmus.com/scope/.

2. Drag the bookmarklet to your bookmarks bar in your browser.

3. Open your webmail and view any e-mail.

4. Click on the Scope It bookmarklet in your bookmarks bar.

5. The Scope site opens with the e-mail in design mode.

6. Click on code and the design panel will slide away and allow us to see all the markup of the e-mail in question.

This is incredibly useful for learning how others are pulling off such amazing things like video on e-mails, gradients, responsiveness, and so on. Here's a screenshot showing us what the responsive e-mail template we just built looks like after sending it to my Gmail account and scoping it with the bookmarklet.

On the left we see the Scope side on Litmus's website, and on the right it's the file opened in Sublime Text. They are exactly the same… even the formatting is identical. Amazing tool!

See how an e-mail was built

E-mail template using Litmus's Scope

Summary

Wow, we made it!

In this final chapter about responsive e-mails, we discussed some important things in addition to building an actual e-mail.

We now understand why e-mail is so important in any marketing campaign, since more and more e-mails are being opened on mobile devices. However, people like to interact with e-mails a lot more on their desktops—very solid reasons to make our e-mails responsive.

Analytics are a key factor in deciding which e-mail clients to support. We want to spend our time wisely. Then, setting up a basic HTML template can go a long way because we can reuse such template over and over.

Things like a CSS reset, wrapping our content in a 100 percent wide table, and creating the inner table is pretty much the go-to process for any e-mail design. We know now that the maximum width of an e-mail should be 600px.

Microsoft's Outlook 2007/2010/2013 versions are the IE6 of e-mail clients: they have very poor support for modern HTML and CSS, but they are the most popular e-mail client on desktop. So using Conditional Comments for nice CTAs and backgrounds is the way to go.

Also, in order to be as efficient as possible, using third-party e-mail templates and drag-and-drop e-mail building services are always an option.

With these final words about responsive e-mails, we have concluded our journey of mastering Responsive Web Design with HTM5 and CSS3, and then some. If you have any questions, don't hesitate to look me up. I will be more than glad to help a fellow web professional wherever, whenever.

We can now strike that same pose the Kung Fu grandmasters from the Shaolin Temple, Shi DeRu and Shi DeYang did in Chapter 6, Working with Images and Videos in Responsive Web Design.

Hi Ya!

Summary

Huge thanks for reading, I hope you enjoyed it!