HTML Emails that Work
Successfully branding a web app requires carefully designing every aspect of its interaction with users. If you’ll be sending any emails to your customers, you’ll probably want to send something a little more impressive than simple plain-text. To do this, you’ll have to code an HTML email. This is not an easy task — making a complicated layout look good in a variety of email clients is an order of magnitude more challenging than making a website cross-browser compatible.
The main rule: forget everything you learned about CSS3 best-practices, and go back to how you coded websites ten years ago. If you don’t want to read past this second paragraph, here are the rules of thumb that inspired all the rest of the tips in this post:
- Keep the total width of the email less than or equal to 600px. You can ensure this by enclosing the whole email in a table with a width attribute of “600”Use HTML formatting tags instead of CSS whenever possible.
- All CSS that you do use (and it’s totally legitimate to use CSS for most things, just avoid positioning) must be inline. You can code your email with CSS in <style> tags in the <head> and then run it through Mailchimp’s free automatic CSS inliner tool to make this process a lot easier.
Layout Without the Box Model
You can still achieve pretty complicated layouts without using CSS positioning, it just takes a bit more work to get everything to look good in a variety of email clients. Some HTML emails get around this layout problem by simply sending an email with a large picture that has all of the email content on it. While these emails are easy to create, avoid this temptation. Having all text in your email as actual text will help please spam filters, is much more user friendly, and will help email clients give relevant text previews of your email.
You’ll have to use tables to achieve anything other than very basic layouts. Using cellpadding, align, and valign attributes on table tags, you should be all set. Properly aligning text and images can be difficult and may require image slicing. Make sure that all images have “display: block” CSS applied to them, or else images that are meant to be displayed flush with each other will have a small separation between them in Gmail and Hotmail (for mysterious reasons).
Adjusting space above and below elements should, in most cases, be done with br tags. You can also use the line-height CSS attribute on p tags, just be sure to test this in a variety of email clients because many handle this attribute differently.
People tend to respond to default blue text links in emails, so don’t stray from this styling unless you have a good reason. If you do want custom links, be sure to define any custom colors within a font tag that is within the a tag. This is necessary because some email clients (like Gmail) make all links target=”_blank”, and in the process, strip out any color CSS you’ve added to the link.
Sometimes email clients will link text that you don’t want to be linked, such as text that looks like a URL or email addresses. There are two ways to deal with this:
- You can control the style of the link by explicitly defining the text as a link and styling it appropriately.
- You can enclose the text in an anchor tag without a href= attribute to make it behave like normal text and prevent it from being automatically linked. This won’t work in all email clients, most notably the iPad/iPhone.
The best way to include images in HTML emails is to host the image somewhere with a publicly-accessible URL, and use that full URL to refer to the image in the src attribute of an img tag. As explained above, all images should have the display: block CSS attribute so that Gmail and Hotmail handle them correctly without adding on extra space between images.
Resizing images isn’t smart in some email clients, i.e. if you just specify a width or a height for the image, it won’t preserve the aspect ratio of the image. If you want to display an image not in its original size, you’ll have to calculate both the width and the height of the image and explicitly write them in HTML. It’s good practice to define the width and the height in both the style attribute and the width and height attributes, because some email clients won’t recognize the width and height CSS definitions. The easiest way I’ve found to determine both the height and the width for an image given only one is to define one and then inspect the element with Chrome to determine the other measurement.
Even if the image will be displayed in its original size, it’s good practice to define the width and height anyway. Many email clients don’t display images by default, and by defining a width and height for the images, the placeholder that the client uses will be the proper size and won’t break your layout. In most email clients, specifying a background-color CSS attribute and a bgcolor img attribute will display a colored block instead of the default image placeholder before the image loads, which can greatly improve the look of your email when images are turned off.
- It’s not currently possible to use fonts that aren’t installed on a user’s computer, i.e. font embedding won’t work
- Avoid custom characters for <li> elements; it’s not possible to define pseudo-classes inline, and Gmail strips out the text-indent property, making it impossible to space it manually.
- Use Mailchimp’s inbox inspection tool (not free) to see how your email looks in multiple email clients and OSs