Email markets - A developer’s guide to a consistent campaign
Posted by: absolute
Emails are a vital marketing tool, with two of the most utilised types being Email Newsletters and signatures. Both of these require HTML / CSS markup, the problem is that you still need to consider archaic software when developing these. Here, our Lead Front End Developer delves deeper into the issue.
While current statistics suggest that majority of emails are now opened on Apple devices you still need to consider Gmail, Android, Outlook and many more. This means that emails need to use old fashioned table based markup and abide to a number of caveats to look as consistent as possible across these different devices and email clients.
Here we aim to give you an insight into the years of experience our web development team have on creating HTML based emails to help you make sure your emails catch the receiver's eye for all the right reasons.
It’s vital to understand what is possible making Campaign Montiors guide to email CSS one of the most useful tools that we use. This gives us an encyclopedia of information on what is possible by email client.
If this is a small project such as an email signature we start with Sean Powell’s Email Boilerplate. This deals with the pitfalls of many email clients by providing resets and a recommended approach for elements such as links and images, even providing specific ways of targeting certain clients. Don’t be put off with the fact this was developed over 5 years ago, while what is possible with emails has moved on the basics to creating a HTML email remain the same.
For Sean Powell’s Email Boilerplate we would advise reviewing the commented version to get an overview of how to utalise the code efficiently and why it’s recommended, before using the uncommented version for development. We would always advise stripping any comments out of your HTML email before deploying to avoid any unintended side effects, you can maintain comments within your source file for future use.
If you’re starting a larger project for example an Email Newsletter we would advise starting with Foundation for emails.Foundation for emails has been created to allow you to rapidly create extensive table based HTML / CSS for responsive emails.
This is a more comprehensive boilerplate for emails using a number of command line tools such as npm and Gulp to write minimal markup that can be deployed with a simple command to generate extensive table based HTML markup. Foundation allows you to break your code down having includes such as your header and footer and allowing you to utalise Sass for your CSS. With this approach you’ll maintain manageable source code, utalising the tools provided to automatically generate the full code for deployment and testing.
Spacing is likely to be one of the biggest sticking points as it’s the hardest aspect to match up across email clients. As the email support table shows versions of Outlook don’t support margins or padding, this can be where many developers hit problems, so we need to find another approach. We would advise avoiding margin / padding where possible and consider it as an enhancement where it is used. While some boilerplates such as Foundation for Emails provide their own built in approach to spacing if there isn’t one in your choosen set up here’s a breakdown of the approach we would use:
By using an empty row and cell with a specified height above and below the content we can create padding above and below elements.
Adding an empty cell with a specified width either side of the content we can create horizontal padding. While this is a lot of excess code it is a solution that works well across most clients.
As some email clients markup out the header and style tags it can prove vital to use an inlining tool. This will add these styles to the elements inline while leaving any media queries in tact. There are a number of options available here but we tend to use either:
While the w3 HTML / CSS validation may not be the go to tool for developers as it once was, we find it can still be handy to resolve many validation issues, which should be simple, but aren't given the excess mark up that can often occur, such as a missing closing tags.
Always specify the height and width of your image on the image element and inline on the style tag to make sure you’re covering your bases across clients. Unless you’re using retina images always save the images out in the exact size you’re using to reduce the size of your email and the likelihood of the email client showing a larger image breaking your layout. For more information on Retina images we suggest you read this blog here.
It’s also worth having a last check that you’ve stated consistent and correct sizes on your tables.
When testing emails we would always recommend testing using Litmus, which produces screenshots of how your email will render on over 50 email clients and allows you to generate your own testing suite. To give a good coverage we would recommend testing on:
Standard (Non Responsive)
- Outlook 2010, 2013, 2016
- Apple Mail 9
- Android 4.4
- iPhone 5s (iOS8) , 6s (iOS9)
- iPad (iOS9)
- Web based
- Outlook.com (Chrome, Firefox, Explorer)
- Gmail (Chrome, Firefox, Explorer)
- Responsive - Android 4.4
- Responsive - iPhone 5s (iOS8) , 6s (iOS9)
- iPad (iOS8)
This will change over time but the Litmus blog regularly provides up-to-date satatstics of what email clients you can exect your emails to be viewed on.
Other tips and tricks
We’ve found using percentages for line heights to be the most cross client compatible approach. While this is the approach we take it’s not foolproof, especially with Outlook, which can inject its own markup. We would advise further reading on this subject to gain a full understanding of what to expect here.
Colspan / Rowspan
Colspan and Rowspan are supported by most major email clients and can be used across the board, however where possible we favour using nested tables. While this creates more markup and can be harder to maintain there are certain quirks in Outlook which can be avoided by using nested tables.
When applying styles to specific text, such as referencing a font family or style, we favour using spans. We also find it can be easier to replace paragraphs with spans where possible using break lines instead of padding, which we know can be inconsistent.
While 100% consistency across email clients can be impossible to obtain with varying email clients, operating systems and servers, we hope this information will help you to get your HTML emails displaying as consistently as possible.