6 Tips for a Less Stressful HTML-Email-Building Experience

Let's be honest, you have to be bit of a sadist to to get into the HTML email building game. As anyone who has been responsible for doing it in any kind of capacity before will attest to: email is a tricky beast. All of those email clients, and all of their quirks and limitations. What seems like the simplest thing can often result in hours of fist-clenching, swearing-under-the-breath frustration. And the techniques used to put an email together seem a million miles away from typical web development. How did things even end up in this state?

But, the fact remains: Email is still a valuable, cost-effective way for companies to engage with their customers. And its popularity as a marketing platform is only set to grow, especially with the rise of smartphone use and "anywhere" internet access. Whining about it will aide us not a jot. Being precious about dirtying our hands with “tables-within-tables-within-tables” HTML will change nothing. Our only choice as developers is to roll up our sleeves and crack on - hopefully finding a way to achieve results as painlessly as possible. 

With this in mind, below are 6 tips for a less stressful HTML-email-building experience. There are a lot of basics I won't be covering, largely because other people have done it so much better (check out htmlemailboilerplate.com if you haven't already, or the Campaign Monitor website for a more comprehensive guide on good practice). I'll also not be going into any great detail about responsive email design, because there's simply not enough room in this post to do the subject justice. Maybe next time?


We know that CSS is an incredibly useful and essential tool when we work with HTML normally, but we also know that styles have to be applied in-line if an email is to stand even a remote chance of looking good in most email clients. But what if you could build an email using all of the time-saving benefits of standard CSS, and have something else cleverly take care of the in-lining part for us? Well, that's exactly what Campaign Monitor (in my eyes, the definitive pro of the HTML email world) allows you to do here, for free: http://inliner.cm/

Using a CSS in-liner means that you can avoid a lot of the soulless repetition normally associated with putting together emails, letting you spend time on more important things. Having all your core styles in one place also means that updates are much easier to make, and your HTML code will be much more lightweight and easier to sift through.

Whether the email is meant as a one-off or a reusable template, and whatever the sending platform might be - I ALWAYS start with a lightweight (non-in-lined) version first; only running the email through an in-liner once everything is signed off. I can't tell you how many hours this has saved me.


Before I start with the actual HTML, I always take a few minutes to create some convenience classes in CSS, to help with font and colour application. For each key colour in the design, I create a class that sets the text colour to that colour, and another that sets the background colour. I'll also name them something incredibly simple/obvious, so that I can use them in the design without having to remember which class to use (e.g. white_text, white_bg, green_text, green_bg)

If the email has a couple of key fonts, I'll also create a handy class for each font style (usually limited to '.serif' and '.sans'), which will apply a sensible font-family stack, font-size and line-height wherever it is needed. Or if the design uses a single font, I’ll create a single 'type' class, that I'll use in the same way. In my experience, creating classes to set individual font sizes barely turns out to be useful, so wherever I need to override the default font-size, line-height or anything else, I find it best to resort back to adding styles in-line (like in typical web development, in-line styles on your elements will take precedence over the general CSS when the in-liner works – smart eh?).


There's still no shortcut for some things when it comes to putting together emails, but you can definitely lessen your chances of display issues by always setting border="0", cellpadding="0", cellspacing="0", and a width on every <table> element you add. You'll also want to add an align attribute to any <td> that has text or anything else inside it. 


In order for most styles to work across the board, you need to apply them to the <td> that your content is sitting in. Anything applied to the <table>, <tr>, or the <td> the <table> is sitting in, just isn't specific enough, and will be ignored by a lot of major email clients. Think of every <td> as a blank canvas that needs any styles applied to it directly. This goes for background colours/images, fonts, and font colours. 

If you want to cheat, and not have to apply a class to every cell, you can be smart and use class inheritance to apply styles to <td> elements within a <table> with a certain class on, but this will often end up affecting cells that it doesn't need to, making the final code more bulky than it needs to be. You also risk getting yourself into a bit of a pickle with certain styles overriding each other when you didn’t mean them to. In my experience, applying classes at <td> level, when you need them, is much more reliable, and gives you a greater level of control.


I remember a time where I thought spacer images were the only way to enforce layout. Thank heavens those days are behind me! All you need is empty table cells – completely empty, to be precise. Don't worry about adding non-breaking-space characters to stop them from collapsing, because it’s not necessary. The trick is to always add a width attribute to set the width on each spacer cell (even if the cell spans multiple columns, or you think the width is implied some other way). You can also create vertical spacer cells, but you need to apply both a width and height value to them. Use this technique and you should have nice, reliable spacer cells that work across all major email clients. Give it a whirl and see for yourself!


For years, email building folk like myself have been a little bit unsure about what is and what isn’t possible with background images in emails. It’s often that case that a background colour fallback just won’t cut it, or it’ll just look more consistent to somehow break the image up, and arrange it into a table in a way that gives you a flat-coloured area in the middle to put your text or image. What a kerfuffle!

But, the future of using background images in emails just got a whole lot brighter! Using an extremely clever combination of CSS, VML and fallbacks to produce a solid, reliable result across most major email clients (even Outlook)... say hello to Bulletproof Background Images: http://backgrounds.cm/

The technique isn’t without its limitations, but I’ve found it incredibly useful for reliably applying repeating patterns, textures and gradients to large areas. By all means, have a play around yourself.


If you’re upset by background images looking less than okay on devices with retina displays, you can create 2x (double resolution) versions of your image, and use a media query in your css (in the <head>, not in-line) to target retina displays, and override the in-line background-image value to the 2x version (using the !important declaration). An example:

@media (-webkit-min-device-pixel-ratio: 2),(min-resolution: 192dpi) {
    #image_bg_cell { 
        background-image: url(bg_image2x.gif) !important;
        background-size: cover !important;

You might have also noticed that I’ve used the ‘background-size’ property to make sure the image scales down to match the width of the cell it’s sitting in. If you have a repeating pattern tile, or need to position the image some other way, you may need to play around with that.  Although background-size is a pretty new CSS3 attribute, pretty much all email clients that are advanced enough to support media queries will support background-size too, meaning it’s okay to use here. You can check which devices support media queries in email here: http://www.campaignmonitor.com/guides/mobile/#mobile-support