If you’ve worked in the world of email design, coding, marketing, or QA you know that getting a well-designed and functional email shipped is no small feat. Every client decides what features they’re going to support, leaving you with a mess on your hands when trying to identify, diagnose, and debug issues with your emails. That’s just half the problem though: if you want to do anything new or innovative, you’re going to spend most of your time just trying to hack together ways to get your email to render.
We all know the reason behind this: sparse CSS support, combined with structural HTML issues, on top of a complete lack of scripting support in email clients. Now, we’re not going to try to convince the major email clients that they need to change their ways just because we’re asking them to. Instead we’re going to focus our energy on making our emails the best we can within the constraints presented to us.
We want to help you do the same, which is why we’ve put together this guide to help you save yourself from wasting weeks on the tiniest issues.
The Most Popular Email Clients
To start, we need to first understand which major email clients we need to care about. As you can see from this chart, courtesy of Litmus’ Email Client Market Share survey, there are a handful of clients that make up the vast majority of email usage. The first spot is the email rendering engine made by Apple, which is in use on the iPhone, iPad, and in OS X’s Mail.app, followed up by the Gmail applications, then Outlook, and then trailing off to include various Android and web-based email applications.
The takeaway from this is simple: there are a few very large players that you should be paying attention to, a few medium-sized clients you should be aware of but not worried about, and then thousands of smaller clients that you shouldn’t concern yourself with at all. By following this strategy, you should be able to make sure your emails render correctly to the vast majority of your address list, without having to worry about hiring a team of engineers whose sole job is to make sure that emails getting sent to an email client from 2002 are still functioning properly.
The Major Difficulties
With that being said, just because you don’t need to worry about a lot of different email clients does not mean styling and creating functional emails is a simple task — it’s not. It would be one thing if email clients all just didn’t support various parts of the HTML and CSS specifications, but the truth is that it’s not that simple. In fact, there are email clients that support CSS features that haven’t even been officially launched yet, while other clients won’t support it for years, and still other clients simultaneously support futuristic features while not even fully supporting the current specifications of CSS and HTML.
In truth, it’s a mess, but it’s one that we want to help you navigate. In that vein, we’re going to break down the difficulties into a few major categories and help explain whether or not you should spend your time in that category trying to make it work.
The first note that we have to make is that even though you may be tempted to put a <style> tag in the <head> section of your email, it’s not going to work. Almost universally unsupported, the <style> tag is only useful when doing the initial coding of your email. This is because if you do write your CSS in the <style> section, you can then later use a tool like MailChimp’s CSS Inliner to strip it from the <head> and move it to each applicable element. This does make it easier to manage the initial design and styling of your email, but it’s still a bit of a pain.
For those that aren’t familiar, the Box Model refers to elements like Borders, Margins, Padding, and Content. According to the W3, “All HTML elements can be considered as boxes. In CSS, the term “box model” is used when talking about design and layout.” Fortunately, unlike <style> tags, the Box Model is almost completely supported in all major email clients. In fact, the only known issues that you’re likely to run into are related to using the radius features in an effort to round your borders. But, even that is partially supported, so that doesn’t rule out a nice rounding effect.
If you’ve coded emails before, you know that tables are supported. In fact, to the chagrin of many an email marketer and engineer, tables are perhaps over-supported. The reason we say this is because tables are essential to the creation of HTML emails, in that many email clients don’t allow you to position and outline your emails without tables. This means that you’re going to spend an awful lot of time nesting table into table into table, all in an effort to make sure your elements are exactly where they need to be.
Positioning and Placement
This brings us to our next point, which relates to positioning and placing elements. As hinted above in the section on Tables, most email clients do not make it easy to position elements without tables. That naturally means you’re likely to find out that “display,” “bottom,” “clear,” and “float” all have intermittent support. Sure, some of these elements are becoming more supported in newer clients, but it’s not yet to the point where you can discard tables entirely.
Fonts, Colors, and Backgrounds
The bulk of your email style is going to have to come from a unique and captivating combination of fonts, colors, and backgrounds. Fortunately, as these are the most commonly used mechanisms to make your email eye-catching, they’re also some of the most supported features in the major email clients. There are exceptions you should be aware of, like issues with embedded fonts and bugs that come up when putting in images of the wrong width (max: 660px, preferably 600px), but overall these are issues that can easily be avoided.
Animations and Transitions
Unlike with fonts, colors, and backgrounds, most email clients do not want you to be using animations and transitions. There are ways around this, with the use of Gifs to provide movement inside of an email becoming more popular in the last few years, but overall you’re going to have to stick with static, unmoving emails. There are some features you can work with, especially on Apple devices, but you should really avoid this for now until there is wider adoption.
Looking to the Future of CSS Support
While the state of CSS support in the major email clients continues to frustrate email creators around the world, the truth is that things are improving. Older clients are less in use day after day, while newer clients are focusing on competing for the attention of email designers and customers. That means more sections of the CSS specification is being found in major clients with every new release. In an effort to stay on top of that, we recommend looking at the CSS support documentation released by both MailChimp and Campaign Monitor. Both of these services go out of their way to make CSS support public knowledge and routinely test the entirely CSS specification on all major (and some minor) clients.