Any developer knows that creating HTML emails from scratch can be seriously challenging and tedious. Not many developers enjoy building emails because the way we write the code for them feels prehistoric, but some words to live by when creating an email from scratch follows.
The older the code is, the more likely it’s going to work in email clients.
I know, pretty daunting, right? But the fact is with facing the challenge of creating an email that works perfectly in every major email client is a nightmare, because a lot of them are using very dated rendering engines which brings me onto my first point.
How to Structure
Always build with tables. The HTML structure that a <table> creates is without a doubt the most reliable way to write an HTML email. If you start to dissect emails that you create in Mailchimp by viewing the source code, you’ll notice that the structure is made from a giant table with many other tables nested within.
In the past, around 1995 / 1996 when tables were first introduced to the web, they were revolutionary, and it made the internet much more of an exciting place. Nowadays, you would rarely ever create a web page using the <table> tag. Instead, we use tags such as <section> and <div> in conjunction with CSS to customise the layout and styling of these tags giving us a lot more control and flexibility over the look of a web page than using a <table> would. However, as I’ve mentioned, we want to go down the prehistoric road and use as many old tags as we can, so the table tag is perfect.
Testing your HTML Email
When it comes to checking your HTML emails, it’s vital you test all of the major and required email clients accurately and thoroughly. Luckily, there are a lot of paid for and free online tools out there to help you test efficiently.
Litmus
Litmus is a web-based email testing environment that allows you to build, test and send your HTML emails from scratch. You can upload zips of your HTML or input the HTML directly into their real-time rendering test editor and then test it in over 40 different email clients ranging from MacMail to Outlook on a range of devices including desktop, iPad and Android phones. It’s a fantastic package, but it does come at a cost. However, if you have the budget, I would strongly recommend this platform for the email client testing feature alone. As getting your emails to work in clients such as Outlook for Windows, when you’re developing on a mac is a problem in itself, with litmus, you can preview the email on in its real client environment and accurately.
Alternatively, you can test the email yourself by grabbing yourself a copy of a load of clients on your desktop and mobile and using a tool such as Putsmail to distribute them. But this can be very time consuming, which is why paying for a flexible service is recommended.
The Hardest Clients to Master
It goes without question that some clients are a lot harder to get your email to work in than others, and just like building websites (in terms of front-end development), this is one of the biggest challenges we face. There are workarounds, however, the main one having the knowledge to know what type of tags and styles will be rendered and which ones are just a bad idea, which I will cover in the next section of the blog.If you’re developing on a mac and testing in outlook, it’s fair to say that a lot of the time you will not see the exact same email being rendered to someone using a windows setup in outlook and the clients have different rendering engines depending on the OS.
What I’ve found is that outlook and Hotmail are by far the hardest clients to please, while MacMac renders correctly nearly every time and Gmail being not too far behind it. You can expect to spend a lot of hours within outlook viewing source trying to achieve a respectable email, which is why you really should consider using an email building platform such as litmus.
Some development tips
If you’re a developer seeking some advice, I’ve included a few tips below of some recent findings I’ve come across recently while building my emails.
Setting your values
Always set your values in pixels. I once made the mistake of setting my values in rems, and it ended very badly in outlook. Following on from this, it’s always best to set your widths on images as an HTML attribute and not a style. For example:
Remember, when setting sizes as HTML attributes like in the example above you do not need to add a value to it. This goes for anything including the size of a <td> or <table>.
Using Padding and Margin
Try to avoid using margin entirely, there are alternative ways to achieve margin between elements and the way the trickier clients such as outlook handle margins is unreliable and inconsistent.
Relying on padding & margin on elements such as an <a>, <li>, <p> is not a bad idea. It gets stripped out of clients such as outlook. If you need to add spacing to these elements ensure you set their padding and margin to 0 And use one of the following approaches:
| <tr><td style=”font-size: 0; line-height: 0;” height=”10″> </td></tr> |
Insert this between whichever elements need a spacer.
If you know what shorthand is, then you’ve probably tried to use on while creating an email, but I would advise against using shorthand’s as the trickier clients can interpret these wrong and return all sorts of weird results, just stick to the old-fashioned way of writing your values.
| ✔ | ✖ |
| padding-top: 20px; padding-right:40px; padding-bottom:20px; padding-left:20px; |
padding: 20px 40px 20px 40px; |
Alternate Approach
Use the <br> tag! The <br> tag rarely ever returns the correct amount of space you want, but it’s better to compromise on a little / less space between your elements than to have none at all and potentially risk the readability of your email.
Don’t overuse <img>
Remember this; Popular clients such as Gmail, Thunderbird and outlook all block image loading by default, the user has to allow the images to load. With this in mind, a colleague informed me that at a previous workplace they took a screenshot of the entire email design, and just inserted one <img> tag with the screenshot as the source and sent that out as the email. Don’t do this; it’s bad for a lot of reasons:
- Including a lot of images in your email may result in it getting placed in the spam folder.
- If your email is 90% images, and the user decides not to load images, then there will be no email/content to look at.
- Images are more laborious to download than text and use up more data.
You can get creative with your images though, as GIF support is universal in email clients.
Background-image
One thing to note is that the background-image style tag is not supported in outlook email clients but here are a few solutions:
You can try to use the code to detect if the email client is Outlook for windows & other clients to force a background image or you can use the background attribute on a table as this has the most significant support.
Creating a responsive email
The trick to responsive emails is using scaling. Essentially, we have our main table which has a set width of 600px. What will happen to this table is the width will be forced to fit edge-to-edge on smaller screens, essentially scaling down all of the content within to fit.
What about media queries?
Well the answer is, sure you can use media queries but a lot of clients will completely ignore them, so you should have a back up in place for clients that will not respect your media queries.
The most significant secret to creating responsive emails is, in fact, the design. Having a design which can be easily modified and scaled down correctly for smaller screens is the key. The image you have a design with four columns full of text, which looks fantastic on a desktop but on mobile how are you supposed to accommodate these four columns without having text go completely AWOL.
In conclusion, building a HTML email can be tricky, but it takes time to learn the correct approach and techniques to achieve the desired design. The most reliable bit of advice is using a tool to do thorough testing and using online resources such as stack overflow to seek help from other developers.