10 Steps for Effective Cross-Client/Browser HTML Emails
When I first started here at thredUP, one of my primary responsibilities as a junior engineer was to handle the html coding and building of marketing emails. Although not considered to be the most glamorous job in the biz, it was made clear to me how important email marketing was to an e-commerce company and for thredUP specifically, it accounts for a huge chunk of our revenue. As someone who was new to the engineering profession at the time, this was the perfect role for me to add value to a growing company while also being able to integrate myself with and learn from a rock solid engineering team.
Prior to my job at thredUP, I had heard the common notion that coding cross-browser/client HTML emails was like taking a time machine back to the ’90s. I had also heard it wasn’t necessarily the easiest thing to get right, and even engineers with multiple years of coding experience under their belts could still find it frustrating the first few times they tackled it. Here I’d like to impart some of the tips and tricks I learned along the way to hopefully save a few hours of headaches and frustration.
One thing I want to mention first though, is that it is impossible to get an HTML email to look pixel perfect for every single one of your users. There are just too many combinations of email clients, versions and browsers, and not a lot of consistency across them all. At a certain point the added stress and time cost of attempting to get it completely right for every scenario will outweigh the benefits. So work smart.
1. Tables within Tables within Tables
The cardinal rule for HTML emails is to use nested tables instead of the <div> tag to space out your content. Using this table inception ensures that you’re email’s structure is the most robust and consistent, since different clients handle CSS properties for divs in different ways.
2. Avoid Margin, Float, and Position
The main culprit here is older versions of Outlook (surprised?) but both Gmail and Yahoo mail don’t support Positioning either. Padding is the best attribute to use here (although for certain tags, Outlook still doesn’t like padding), but if you want spacing that is completely consistent, I’ve found that the best thing to do is create empty table cells with explicit width/height attributes.
Check out Campaign Monitor’s guide to CSS support for a breakdown of which clients support what.
3. Use inline CSS.
Most email clients will strip out the CSS in the head and body tags. Always use inline CSS when coding html emails.
4. Set specific Height and Width, for images and tables.
For images, some clients will automatically apply their own dimensions where they aren’t explicitly stated, which leads to spacing and alignment issues. I’ve seen this happen for tables as well, so to be safe, always have explicit height and width properties to force a box-model structure.
5. Alt texts for Images
A big reason for having alt texts for images is the case where the image cannot be rendered. Sometimes this is due to image blocking being enabled within the email client or possibly because of a slow internet connection. An alternate text can still convey the message/intent to the user in these cases. Another reason is for users who have disabilities and use a screen reader, they can still get context from the alt attribute.
7. Explicitly set Border, Cell-Padding and Cell-Spacing to 0 for your tables
Unless you want additional spacing between your tables/cells, make sure you explicitly set these attributes to 0 in all of your table tags. I found this very frustrating when there were random gaps in-between images/cells in some clients but not in others.
8. Use a Pre-header
More of a general best practice than coding, but always use a pre-header in your email templates. This is the first line of text that appears next to the subject line in email clients and can give more context to your customers regarding what the email is about. This can make a big impact on your open rate if executed correctly.
9. Send a Plain-Text version as well
This is related mostly to deliverability but it’s always a good idea to send a plain-text version of your email along with the HTML version. The main reason is that ISP’s have evolved over the years to try to protect their users from spam and unsolicited messages. One high indication of a spam email is heavy on images and low on text, and when you don’t include a plain-text version it looks like you’re trying to slip something past these ISP filters. There’s also the possibility that a really old email client won’t display HTML emails at all (rare these days but still happens), and thus a plain-text version can still get across to your users.
10. Use a service like Litmus or Return Path
I name these two because these are the ones I’ve used but there are a number of services out there that accomplish the same thing. You can send a test email to these sites and they will let you view what your email looks like in multiple different clients and browsers. Return Path also does a lot more related to Sender Score and deliverability as well.
Also, it’s always best to send a few test emails to your own user accounts. I typically test emails myself in various browsers and my own mobile device (iPhone 6s) just to double check. #beparanoid
A few more tips and links
I didn’t touch on responsive emails here, but checkout this post by Mailchimp for getting started with media-queries in HTML emails.
Is the Gmail iOS app automatically resizing your text? Take a look at this quick and easy (and hacky) solution.
And finally, don’t kill yourself trying to get it to look one hundred percent amazing in all possible email client/browser combinations. If possible, determine the top clients that your customers are using and optimize for those situations. Litmus compiles a list of the top email clients by market share (although they claim that “the data for some email clients and mobile devices might be over- or under-represented due to automatic image blocking”).
Well, that does it for this post. Best of luck and happy coding!