Next week, we’ll be launching a brand new set of default email templates for CheddarGetter. We learned a ton about coding and designing responsive and highly-deliverable emails through the process.
From the get-go, we had a few goals for the new templates in mind:
You’d think accomplishing these goals would be pretty straightforward. Unfortunately, coding emails is hard. We knew we wanted to create something mobile-first, but we weren’t quite sure what the best practices were or where to get started. THANK GOODNESS there are awesome resources out there. We really liked the mobile-first, single column approach we found here. Since notifications we send are transactional emails, not visually dynamic marketing emails, a single column structure works really well. It also makes editing the content a little less complicated.
According to FogCreek’s approach, our single column email should scale to fit smaller screens, but it shouldn’t get too wide to read in desktop clients. A max-width table does a pretty good job of restricting the email’s width in most email clients, but, as is often the case with emails, there are a few clients that don’t support this property: Apple Mail, Outlook, and Lotus Notes.
While Apple Mail doesn’t support “max-width,” it is one of the few email clients that supports media queries. By creating a style tag in the head and inserting this media query,
@media only screen and (min-width: 541px) {
.cheddar-content {
width: 540px !important;
}
}
we can restrict the .cheddar-content table to 540px wide if the window is greater than 541px wide.
Neither Outlook nor Lotus Notes 8 support the “max-width” property. Luckily, these rogue clients are mostly used to view emails from desktop computers, so we don’t need to be as concerned with responsiveness here. A fixed-width table does the trick. We’re applying a few conditionals: (IE) covers Lotus Notes and earlier versions of Outlook, while (gte mso 9) covers Outlook 2007+. There’s also an identical conditional in the footer of the default notifications that contains all the close tags for this table.
<!--[if (gte mso 9)|(IE)]>
<table width="540" align="center" cellpadding="0" cellspacing="0" border="0">
<tr>
<td>
<![endif]-->
Now that we’ve gotten the basic responsive structure out of the way, let’s take a look at the email head. There are several differing opinions about the best DOCTYPE, HTML attributes, and meta tags to use in your emails. Below, we’re listing the ones we’ve chosen to use and why. If you’d like to learn more about email boilerplating, you can check out this interesting discussion on the Litmus community forum.
<!DOCTYPE html>
We’ve chosen HTML5 as our DOCTYPE. This DOCTYPE tells the browser/email client to render the layout in standards mode, not quirks mode, and it’s required for standards validation. It is technically experimental, but in email testing and W3C validation, we haven’t run into any issues.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
The Content-Type meta tag is what controls the display of different character sets. Usually you’ll want to use utf-8.
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
This tag forces Windows Phone 8 (and anything else rendered with IE) to render in highest capable standards available, allowing CSS3 and preventing rendering in quirks mode.
<meta name="viewp0rt" content="width=device-width" />
Since we want our email to be responsive, we’re letting the browser/email client know that our layout will adapt to the device width. NOTE: We’ve purposefully misspelled viewport in our code example above to combat a mobile rendering issue we’re having with our blog (Spelled correctly, it was somehow being read as real code, and overriding the true viewport setting. Weird, huh?). You should definitely spell it correctly in your real email code.
<title>{$subject}</title>
Emails without a title will trigger W3C validation errors. Also, some email clients (like Gmail) actually use the title tag. We’ve added the subject of the email as the title as a default.
<link href="https://fonts.googleapis.com/css?family=Open+Sans:700,400" rel="stylesheet" type="text/css"/>
B-B-B-ONUS: We’re using a webfont! This doesn’t work across all email clients (and, in the case of a few versions of Outlook, requires a bit of a hacky fallback, adding .cheddar-body-text to all parent text elements to prevent everything getting all Times New Roman-y), but it does make the default emails feel much less generic. You can learn more about using webfonts in emails (and which clients support them) in this article by Litmus.
<!--[if mso]>
<style type=”text/css”>
.cheddar-body-text {
font-family: Helvetica, Arial, sans-serif !important;
}
</style>
<![endif]-->
<style type="text/css">
@media only screen and (min-width: 541px) {
.cheddar-content {
width: 540px !important;
}
}
</style>
We know, we know, this looks absolutely insane. TWO STYLE TAGS?!? The first, with the “if mso” conditional, is a fallback for the webfont. If left out, many Outlook clients will default all text to Times New Roman, and it looks gross. The second style tag is for our Apple Mail “max-width” media query. We DID try to insert the conditional with the font fallback inside a single style tag, but it caused a LOT of rendering issues in testing. Luckily, these two tags don’t interfere with each other. Outlook ignores the second <style> tag (whether that’s because it just doesn’t accept two style tags and only applies the first, or if it gets ditched because of the media query, we’re not quite sure). And all non-Microsoft clients ignore the first style tag because of the “if mso” conditional.
So, we’ve got the basic bones of a great, responsive email. Now it’s time to give it some style. Unfortunately, many email clients don’t allow <style> tags or imported stylesheets in the <head>. The most reliable way to style emails is with inline styles applied to parent elements, and only using <style> tags for specific reasons. To take the brutal copy/paste mundanity and general disorderly appearance out of this process, we’ve used Smarty assign variables that make changing these styles and adding them inline much simpler. These assign variables also make it a lot easier for our users to customize things like their brand colors and fonts. By changing them in once place, where they’re declared in the head, Smarty cascades these styles to the individual elements, adding them as the inline styles that email clients prefer. You can learn more about assign variables in Smarty’s article on Built-in Functions
Once we completed our basic template structure and added the styles we wanted, we tested, tested, and tested some more. For comprehensive email testing, we subscribed to http://www.litmus.com. It can be a little pricey, but it makes previewing your emails across a wide range of clients SO much easier. Certain gaps in compatibility came to the surface during the testing process. For example, not all email clients support the border-radius property we applied to the header (we’re looking at you, Outlook). Though obnoxious, that sort of style inconsistency isn’t the end of the world. A more disconcerting discovery was that we couldn’t successfully apply the conditional Outlook font fallback inside the same style tag as the Apple Mail width fix, hence the double style tag craziness. Once the defaults passed Litmus testing (pointy corners in Outlook aside), the emails were good to go!
Find out more about our new templates and how to use them in our Notification Templates Knowledge Base article.