Writing cross-client HTML email

HTML email (EHTML) is a fantastic tool for businesses to communicate with their customers. You can track which links have been clicked, work out conversion rates and the marginal cost of each email is virtually zero.

Creating a reusable email template is no simple task though. Unlike in the browser world where there has been a fair amount of progress towards the adoption of uniform display standards, in the email world there has been almost none. There isn’t enough cross client support for modern web standard for you to be able to use them.

This document is a reference for the html and css that you should use to get the most consistent cross-client viewing experience. It’s aimed at web developers who code up html emails.

This document does not deal with spam filters, stuff that you legally need to include in your html allowing people to opt out, writing content, how to setup tracking with Google Analytics, software to use to send the emails, managing emails lists or other things which are all important and that you may need to research depending on your particular role.

Many clients and a total lack of consistency.
There are many webmails clients such as gmail, hotmail and yahoo mail, as well as several other ones. Some of these have ‘classic’ versions which may display the same html email differently. Most ISP’s have their own webmail clients, which are either customised versions of an opensource product such as SquirrelMail or areis something completely custom. Because your html email has to display inside a container on an html page (html within html), any webmail clients will chop and change your html in one way or another, in particular they will modify css. Surprisingly enough, GMail is actually the worst offender and has terrible CSS support. The same email even may look different in different browsers using the same webmail client with Firefox ignoring padding in GMail.

There are many desktop email clients such as Microsoft Outlook and Windows Mail. While some of these such as Mozilla Thunderbird have excellent support for web standards, others which make up a large portion of the email client market such as Lotus Notes have horrible support. Even the recent versions of Microsoft Outlook have pretty bad support for web standards.

Authoring with PHP and other scripting languages
EHTML can get very complex quite quickly so handcoding is only going to be managable for simple emails. For moderately complex emails you simply have to use a programming language to do the bulk of the world, preferably a scripting language with good xml and regular expression support such as PHP or Python. Usually the best approach to take is to create a document using a markup language (not necessarily HTML) and run it through a script that converts the markup in it to EHTML.

CSS
Cross client support for CSS is quite simply horrible and most attributes simply don’t work cross client. For instance:

Padding doesn’t render in Gmail in Firefox

Margin doesn’t render in Hotmail

Just about nothing renders in Lotus Notes

Infact the only css attributes that will reliably render are:

color

font-family

font-size

font-style

font-weight

text-align

text-decoration

As you can imagine, tableless layout simply won’t work, so you have to use tables for columns, though this isn’t so bad since there’s no SEO to worry about and accessibility is handled by including a plain-text version of the email.

There are 3 ways to have css in your document.

Via a <link> element to an external stylsheet and set by <p class=”…”>

Via a <style> element and set by <p class=”…”>

Embeded within an element via <p style=”…”>

For security reasons, most clients will strip out <link> elements. Most webmail clients will either strip out <style> tags or mutilate them. This is done because it would otherwise be quite easy to be evil and write something like <style>body {background-image:url(“http://www.evilwebsite.com/evil.jpg”);</style> and completely stuff up the webmail client. Embedded css in every element is an extremely inefficient way of using css, but it’s the only reliable method for styling without resorting to <font> tags.

Spacing without CSS
You can’t rely on css padding or margins and Gmail in firefox ignores the table.cellpadding attribute. One method for doing cross client spacing is to surrond the element with a table and setting the width and height attributes of the <td> tags.

Obviously this is an extremely innefficient method for creating spacing, but it’s one of few reliable ways of doing it. You will definately want to use a scripting language to do this, probalby via XML DOM. Once you do this you’ll realise that it doesn’t actually matter that your EHTML is ugly as hell because it still renders well, the only real negative is the extra bandwidth that it takes up if you are sending out thousands of emails.

Setting background-color and background-image without CSS
Use <td bgcolor=”#FFCC00″> and <table background=”http://…/.jpg” respectively

Images
By default, many clients do not download and display images because spammers often track which email addresses download images so that they know which addresses are currently active. Some people will have images permanetly disabled because they connect to the internet via 56k, 3G and prepayed connections where bandwidth is at a premium. Users are usually given an option to download images from sites they trust, though user won’t always choose to download the images.

This means that for a lot of users, they will never see the images that you spent so long creating for your email. Most clients will display an image placeholder instead which is rectangle with a 1px black border. This make it important that you fill in the ‘alt’ attribute for images so that some text displays inside the image placeholder. Also, fill in the ‘width’ and ‘height’ attributes so that the placeholder is the correct size, However, keeping with the theme of absolutely no consistency, some clients will ignore these attributes and show either a generic sized placeholder, or even no placeholder at all. This is one of the reasons why you shouldn’t use spacers because they don’t always render (spacers are transparent .gifs used to set the size of columns and rows).

Email width
Emails are typically displayed in a viewing pane so you should author your emails to be between 400 to 500 pixels wide. The wider it is, the more likely that large portions of it will be hidden from the user – not a good thing!

Some viewing panes are horizontal, some are vertical, and some clients don’t have them at all. Here’s an example of a typical vertical viewing pane. As you can see, even though the email is only about 500px wide, some of it still gets cropped off. Even more of the email would be obscured if the email was 800px wide.

Doctypes, <html> tags, etc
Do not include Doctype or any <html> or <head> or <body> tags since they don’t actually do anything and you’re not trying to follow any modern web standards. Nor is there is no such thing as ‘quirks mode’ for email clients. Most webmail clients will strip these out anyway, though some older ones won’t so you’ll end up with two sets of Doctypes etc.

Javascript and flash
These are stripped out in virtually all clients because they are deemed a security risk.

White space and line breaks
Some clients don’t ignore whitespace and insert a bunch of unwanted spaces into your email. The solution is to not have white space in between tags. Since you’re using PHP or similar to write these emails, this will probably happen by default.

However you should still insert some line breaks. Once I had an email that was getting excessively mangled in particular ISPs ancient webmail client. Turned out the problem was there was no line breaks in the email I was sending out and for whatever reason, their crummy email software couldn’t handle a really long line of html. The answer was to put in line breaks after block tags i.e. after </p>.

width – if you are using a table for you root node, then don’t use width=”100%”, use a fixed width instead. Width=”100%” is fine for inner tables

cellpadding – is ignored by gmail in firefox

border – important that you explicly set this to zero because some clients will default this to “1” which is extremely ugly

<td>
<td valign=”top” align=”left” bgcolor=”#FFFFFF” width=”50″>

bgcolor – Behaves like css background-color.

valign – Set it to top so that it behaves as you’d expect. Defaults to middle. Behaves like css text-align.

align – Generally you’ll set this to left so that it behaves as you’d expect. Behaves like css text-align.

Rely on the width attribute to set column size. You can’t rely spacers (transparent gifts) to set column sizes because a lot of email clients will not display images and some clients will display then as width=”100%” image placeholders.

<p> / and other block tags such as <h1>, <h2>
<p style=”line-height:1em;padding:0;margin:1em 0;”>

Set all of these attributes to act a ‘reset’ for any inherited css – for instance Yahoo Classic will default to margin:0

Hotmail will ignore whatever you set margin to, so it’s best to not use anything except margin:1em 0; so get thing to display better cross browser.

target – it’s important that you set this to “_blank” so that when the user clicks a link it opens in a new window. If you don’t do this then it will open in the same window, thus annoying the hell out of your users who may have a whole bunch of emails to read.

text-decoration – hotmail will default this to text-decoration:none;

<b>

Just use it as you normally would, though use <b> instead of <strong> for really ancient/weird email clients.

Post navigation

7 thoughts on “Writing cross-client HTML email”

I’m not sure how I found this article searching on the Internet, but it was extremely useful. I’ve read a lot of articles about html email, this one is very concise and the links were very helpful. From one Developer to another – Thank You!