Building Responsive Email Templates with Ink

Ink is a responsive HTML email framework by Zurb - the very awesome team that built Foundation. Ink tries to make it easy to build custom and responsive HTML emails that work on all devices.

This article will take you through the fundamentals of Zurb's Ink platform as well as covering some best practice email things. We'll also build a large boilerplate to copy and paste code from. Be sure to check out the demo links or GitHub.

The sad truth about email

If you've never had the pleasure of building a custom HTML email template before, let me try to explain what it's like.

Imagine you were tasked with building a website. This website needs to work in Internet Explorer 6, 7, and 8. On top of that, each version has 10 other versions like it, but they are not quite the same. All of them have their own special quirks and rules. On top of this, you don't have a nice Chrome Inspector or Firebug tool to debug with. Oh, and then you somehow have to figure how to make it responsive and use new cool tools.

It's like building a website for 50 different Internet Explorers, blindfolded.

A lot of good front-end developers will refuse to do it. In a lot of cases, it's assigned to junior devs to basically burn inexpensive hours on until the templates are hacked into completion. If you're that poor soul, take a deep breath and relax, Ink has already fought this battle for you. This article will take you through core concepts of using Ink to successfully build cross-device and responsive custom HTML email templates.

Step 1: Sync up with your designers

This is an important step that's not really part of the Official Ink Documentation. With all the cool new features of CSS3, designers can get away with pushing the boundaries of the web. Unfortunately with HTML emails, that's not the case at all.

Container size

Zurb Ink has a fixed max-width of 580px for content. This size is optimal for all devices. This is done with "containers" (similar to Bootstrap and Foundation).

For devices and screen sizes of 600px and below, the containers will fill 95% of the screen's width to prevent bleeding over a screen's edge.

Responsive sizes

Zurb Ink has only two media query break points - Desktop and Mobile. Mobile begins when the container is equal or less than 600px (when the container switches from a fixed width to a percentage width).

If a designer is creating mobile templates as well, this doesn't mean they should build templates for 600px wide. They should be building for the minimum sizes first (mobile-first approach).

This will help prevent things like this from happening:

I recommend having them build the mobile PSDs with a width of 320px to make sure they look best on iPhones and other small devices.

Custom font's won't always work

Using custom fonts will work real nice on a lot of new email devices, but, unfortunately, a lot of legacy email clients won't load these fonts. There's no work-around for this either.

So in summary, you can use custom fonts, but expect a fallback to be used for a lot of devices. We'll cover how to add custom fonts later in this article.

Simple stacking for the responsive grid

When Ink's grid stacks while switching from desktop to mobile, it's going to do so in a normal floating order. In Bootstrap and Foundation, you can reverse that stacking order. Unfortunately, since Ink's grid system has no choice but to be built in tables, it's not really possible to do that without extra markup.

Key concepts

Firstly, Ink's Official Documentation is amazing. It covers everything in detail and more. I highly recommend spending an hour and reading it through. We'll cover mostly everything in the docs and then some other helpful tips.

Assume nothing works

Email clients aren't browsers. A lot of them only support the bare minimum of what's required for HTML and CSS. On top of likely being buggy or incomplete, for security and other reasons, they strip out a lot of things.

So there's things you'll want to just completely avoid for maximum cross-client support (some more obvious than others):

JavaScript

Iframes

Non-inline styles

The <div> tag to manage layout

Forms

Inline everything

In order to get your styles to work on all clients, you'll need to inline your styles. This doesn't mean you have to do it during development, but before sending out the email you'll need to do this.

Fortunately, nobody does this by hand. There are plenty of resources to do this for you. On top of this, email services like MailChimp, Campaign Monitor, Mandrill, etc. usually have a service to do this for you. If it doesn't, you can use this inliner by Zurb to automatically do it:

Specify all image sizes

Ink has a reset on all images to ensure that their max-width never exceeds 100% (aka responsive images). Outlook doesn't care though. If you don't specify a size on an image, Outlook will be a mangled mess of overflowed craziness.

If you want to support Retina images, you can just add an image that is twice the size of the specified image.

Remove automatic format detection

I personally love that a lot of clients, especially on mobile, automatically convert dates, phone numbers, and emails to links; however, there's always that random use case where you might not want to have that happen. Here's how you can stop it:

If you're on a device under 600px, the <p> tag will still be red. This is because @media rules can't be inline styles. So the inline styles take precedence over the normal CSS just like it would on a website. To override the inline styles, you must use the !important tag.

Testing and debugging

Everyone will have their own method for this. I recommend building the emails in Chrome as you normally would with any other basic HTML page. This way you can visualize the desktop and mobile stuff as your building it out. You'll also be able to use the inspector to get things buttoned-up.

To debug, you should definitely be using Litmus. I can't imagine taking an email project on without it. They have this testing service that will actually take a screenshot in every type of client possible. This is great for testing the Outlooks as well as mobile devices.

The screenshots are even shareable so you can get approval from your manager or the client in case there's any discrepancies.

Adding custom fonts

To add custom fonts for maximum cross-client support, you should use @import inline.

Following this, you'll want to specify the font-family more specific then you normally would. You should assume fonts won't be inherited. On top of that, the Ink framework is very specific on font-familys. Below is an example of how to add custom fonts as well as some simple utility classes for them.

Add a preheader

Some email clients, like Gmail, will preview the first text that exists after the body tag. This is really great except when your email template has text that isn't relevant to the content beforehand. The most common hiccup are when templates that have a "View in Browser" button in the header or something.

To guarentee you have a solid text preview, you can add a preheader immediately following the <body> tag. Here's what it will look like:

Default grid

You'll probably use the default grid the most. Since the grid is built with tables with cross-client in mind, there's a ton of markup to do seemingly simple things. At first it might seem exhausting, but it will save you a lot of time in the future if you're buttoned-up about it.

So let's break it down. Here it is with fake-markup to help visualize the steps:

Block-Grid

I really didn't get the purpose of this at first, but the Block-Grid is actually very useful in some cases. Think of the Block-Grid as a way to do floats in an organized way or something similar to display: inline-block on a bunch of divs.

This definitely has some benefits to it, but it shouldn't be used as your main templating grid in most cases. You'll see in their docs and from the demo that the grid doesn't always line-up.

You'll notice the side-by-side commented code. You need to eliminate space between the <td> elements because they're display: inline-block;. This is nothing special to Ink because a row of inline-block elements create spaces between them. Check out Fighting the Space Between Inline Block Elements by Chris Coyier if you're curious to why this happens.

Full-width rows

Sometimes you'll want to a full-width row. These are good for your headers and footers, but it can even be used in the main content area if you want.

A quick trick to get these working is to just take the default Grid and simply swap the .row and the .container classes. Here's an example:

Buttons

Something as seaminly simple as creating a button is quite difficult to support in Outlook. Sizing just doesn't work well. Fortunately, Ink provides a way to create buttons that not only look in all clients, but they are also responsive.

Miscellaneous things

Visibility classes

Unfortunately, Outlook won't support these classes at all. So if you want to support Outlook, you'll have to use Conditional comments with utitlity classes. This seems crazy, but this is what you have to do:

Panels

Panels don't really do much, and I think they are quick to confuse some. They're not some extra functionality as much as a simple style utitlity class.

Hopefully you're noticing by now that all your content, regardless of the grid choice, will go inside of the final <td> tag. This is always the case with Tables and with Ink.

So, Panels in Ink is simply adding the class .panel to that final td to get some default styles. This is good for protyping and visualizing the grid, but it's not a special componenet or anything.

Conclusion

That covers almost everything there is about Zurb Ink, responsive emails, and then some. Zurb Ink has been around for about 2 years now. Hopefully this guide will still prove useful to people who are just now diving into the framework.

Make sure you check out our demo and GitHub page for this tutorial!

If you have any questions or need support, feel free to make a comment - or even better, ping us in the forums. I'm pretty well versed with this now and should be able to help debug any issues or questions you have.