Keeping code clean in the messy world of email newsletters

Obviously putting the font-family in the table or a surrounding div should do the trick, and it does for everything except Outlook 2007, for some reasons font-family declarations do not cascade. One easy but tedious way to fix this issue is to put inline styles all over the place. I don’t like this method, it makes it easy to forget sections of copy and it messy. I always especially avoid using inline styles on paragraph tags. You have have almost no control on the p tags anyway. Put everything you need in your td tags and leave your p tags clean.

So you might be thinking well then I’ll just add font-family declarations to all my td tags. Again this is slightly less messy, but still messy and our newsletters markup are awfully messy as it is. This is a place where you can use an embedded style. I know there are blanket rules like never user anything but inline styles, but this is not always the case, and blanket rules never benefit anyone. There are places for embedded styles, and they are even required in some cases for optimal cross client compatibility as I wrote about in “Outlook 2007, inline styles, and links“. The thing you must always remember when using embedded styles is that other email clients like Gmail are going to ignore them completely, so build in redundancies.

Style the table data

The fix is simple, you only need to declare your font-family twice. Use an inline style once in your table.

<table border="0" cellspacing="0" cellpadding="0" style="font-family:font-family:Verdana, Geneva, sans-serif;">

At the top of your page add this to your embedded style.

<style media="all" type="text/css">
td {
     font-family:font-family:Verdana, Geneva, sans-serif;
}
</style>

Now you have made Outlook 2007 happy and given every td in your email newsletter a font-family. When the embedded style is stripped in other clients like Gmail you are still keeping the client happy, because other clients won’t ignore the font-family in the table tag and it will actually cascade throughout the document.

First someone is viewing a newsletter their attention span is probably extremely short. They probably want to get onto their next email, but something has triggered their interest in your newsletter. Why waste that interest on jumping them further down the email, this is your chance to grab their attention and hook them into your website. It may be your last change before they click onto their next email and your website is probably a much richer web experience anyway.

The second reason is anchor links are just another thing that often goes wrong in email newsletters. They act unpredictable, and at the time of this writing, don’t even work properly in Gmail. I also remember a time when an anchor link would show a blank screen in Yahoo! Mail, although this has since been fixed.

Despite these reasons, using an anchor links in an email is usually not my decision to make, so I have to try and find a way to make it work. A regular anchor link like the one below will not work in Gmail.

<a href="#section1">Section One</a>

However this will work.

<a href="#section1"><span>Section One</span></a>

Like many email newsletter hacks and tricks it’s a simple one, but can be frustrating and time consuming when trouble shooting it for the first time.

Styling the paragraph tags

Luckily at least with my tests you don’t need inline styles, so you can use an embedded style sheet at the top of the newsletter. If you have worked with email newsletters for awhile you probably already know that most styles should be made inline, but inlining paragraph tags can be tedious depending how man you have. This fix should work either embedded or inline, so it’s up to you which method you choose.

p {
      margin-bottom:1em;
}

Option 2:

<p style="margin-bottom:1em;">Your paragraph</p>

This should fix your Yahoo mail paragraph woes, at least until they break change something else.

Why do I care? It works in the email clients I tested!

That’s fine and dandy, but your audience may be using a client you haven’t tested, one like say Outlook for web. I dealt with an issue like this recently where Outlook was truncating the body copy after the first comma appeared. It was a mailto confirming attendance to an event, so losing the copy was not very helpful for for the end user or the organizer trying to get responses. Now granted a web form would have been a better option, but time restraints resulted in using a simple mailto.

Lets quickly go over some of the mailto syntax.

Subject

mailto:me@myaddress.com?subject=Hello

Body

mailto:me@myaddress.com?body=I will be attending the party, it should be a blast

Subject and Body

mailto:me@myaddress.com?Hello&body=I will be attending the party, it should be a blast.

There  are also CC and BCC values that you can drop into your mailto string.

These examples will work fine in most email clients, but not all. First if you want valid XHTML syntax your ampersands should be &. This should not affect your mailto functionality either way, but having valid markup is always a good thing. Second you should use hexadecimal values for your spaces and commas. Here’s an example of a safer mailto.

Subject and Body

mailto:me@myaddress.com?Hello&body=I%20will%20be%20attending%20the%20party%2c%20it%20should%20be%20a%20blast%2E

The only difference with this example is %20 for spaces and %2c for commas and 2E for a period. This example is much more bullet proof than the first example although you probably don’t need it for the period, but then again I thought the comma would be safe.

Another character you may need is a line break. %0A will give you a line break. Using two will give you a paragraph space.

mailto:me@myaddress.com?Hello&body=I%20will%20be%20attending%20the%20party%2c%20it%20should%20be%20a%20blast%2E%0A%0AI will be bringing a guest too%21%2E

If you are ever unsure of a character just drop it’s hex value in place of it. Most of the characters should work fine, but some like the comma will not. Others like spacing must be added if breaks are needed. You can easily find hexadecimal code lists all over the web, just remember to add the percent (%) symbol in front of the hex.

If you have been making email newsletters that work in the majority of email clients out there you already know this; if you want your work to display the way you intended in web based and stand alone email clients then you have to use inline styles and tables, and a lot of them. You would also be wise to ignore any modern CSS, because most of it won’t work. Inline styles work well for email clients that strip out all the embedded styles like Hotmail (also a Microsoft product). Hotmail has come a long way over the past 4 years, but unfortunately Outlook took several steps back when someone came up with the brilliant idea of using Word as the email render engine. Previous versions of Outlook are much easier to support. 

I’ve done everything right, why are my links turning purple when clicked!

So you have your inline styles set up everywhere including on your links, but when you send out your deployment the links turn purple when clicked in Outlook 2007. This is Outlook ignoring your inline styles and applying the default link colour for visited links. If you have an embedded style at the top of the page, it will respect those. I had stopped using embedded styles all together since inline styles were much more reliable. The fix for this is to add your link styles back in the embedded style at the top of the page inside the head of your markup.

<style media="all" type="text/css">
a:link, a:visited {
     color:#64698c;
     text-decoration:none;
}
.sideBar a:link, .sideBar a:visited {
     color:#893d00;
     text-decoration:underline;
}
</style>

In this example all link styles are set to a specific colour and the second style sets a different set of colours for links within a sidebar class. All you really need to fix your Outlook link woes is the a:visited declaration, but it can’t hurt to add the links in there too.

Inline styles are still king with email

Remember, dont’ get rid of your inline styles. One of the reasons I got rid of my embedded styles is because I could not tell when I was missing an inline style. This is a real pain for links, because using this fix will show your links as the right colour while working on the email. If you or others use editors to work on your HTML they will not add inline styles, so you must always remember to add them after. Again, the down side with this fix is now you cannot see which links you have missed. At the time of writing Gmail still strips out the embedded link styles and I’m sure a few other clients still do this too.

Today I came across a bug that left me fuming. I could not figure out why every single cell in my table heavy layout had a 1px padding around it and in some cases I was even missing my table borders. For those of you working in the sane world of web design, tables are a thing of the past, but in the world of email, tables are back with a vengeance.

As I became more and more disillusioned I started trying anything and stumbled across the fix. I knew I had to share this, so if you are experiencing any of the above, here is the fix and it’s a simple one.

Here’s an example of what a two cell table with an image and text would look like before the fix. Notice the 1px white border/padding around the table.

And here is how it’s supposed to look after the fix. No white border / padding.

And the fix?

table td {
    border-collapse: collapse;
}

I don’t think I’ve ever even used this css before, but once I started grasping at straws I began to fiddle around with the CSS border attributes and tried it. I’ve never seen any browser or mail client except Outlook 2007 do this to table cells.

Here’s the full HTML from the example, and thank you Microsoft, for delivering the worst email rendering experience yet, we all thought Hotmail was bad, but you really stepped up to the plate!

<html>
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Outlook 2007 Test</title>
  <style media="all" type="text/css">
  table td {
    border-collapse: collapse;
  }
  </style>
  </head>
<body>
  <table width="200" border="0" cellspacing="0" cellpadding="0" style="border:solid 1px #48463b;">
  <tr>
  <td width="80"><img src="http://yourserver/graphic.gif" width="80" height="40" alt="graphic"></td>
  <td width="120" style="background-color:#c1beb1; color:#ffffff; font-family:Verdana, Arial, Helvetica, sans-serif; text-align:center; font-size:11px;">Another column<br>
  plain text.</td>
  </tr>
  </table>
</body>
</html>

You may also want to check out my other entries on this topic.

• Outlook 2007 – When is 200 pixels not 200 pixels? Spacer gifs
• Email html design and deployment quick tips

There are some simple rules you can follow which should make life a lot easier. Testing of course is still required and many strange anomalies will pop up. Web based clients change without warning, so constant testing before every email deployment is a must. Below is a quick list of things to watch out for.

• Use tables, tables are your friend when it comes to email deployment.
• Use spacer gifs, yes you heard me right, spacer gifs are far more reliable in the world of email clients. Also check out my entry “Outlook 2007 – When is 200 pixels not 200 pixels? Spacer gifs“.
• Use inline styles on your links and put all text styles inline in your <td> tags.
• Don’t use UTF-8 encoding; you will get gibberish in some mail clients, use HTML entities when possible and Western European encoding, aka charset=iso-8859-1.
• Try to avoid using images for text, especially titles or body copy as most clients are blocking images. This rule could vary depending on your target demographic. People are probably more likely to turn on images for a game newsletter or tech savvy newsletter.
• Have an online version available linked at the top of the email. e.g. “Trouble viewing this email? Try our online version”.
• Avoid fancy CSS like position and float; stick to basic style attributes like font and padding, even margin will be removed sometimes.
• Build white space margins into your images and use HTML align=”right” to align, not float.
• Use background images sparingly, some clients remove them.
• Try not to rely on doctypes, in fact I remove them so I can see how my emails will look without them, although you may find cases where you need them with earlier versions of Outlook.

This list sounds pretty horrible and restricting if you are a standards compliant HTML coder like myself. You probably feel like you have just been kicked in the face and stepped into a time machine and the year is now 1996. This is the way the email world is. Just when you think one client is fixed something else comes along and destroys all hope. Hotmail was the worst client to support for a long time, but their new live mail isn’t half bad at rendering emails. Just as hotmail was fixed a new abomination arrived called Outlook 2007 which uses word to render all emails. You may want to check out my earlier entry titled “Outlook 2007 – When is 200 pixels not 200 pixels? Spacer gifs“.

If you are new to email coding expect a lot of growing pains. Remember that redundancy is the key. For example, if you use a style like img { border:none; }, add an inline style=”border:none”, or even better yet use border=”0″. You may find issues with even simple HTML elements like <div> tags not working the way you expect. The culprit will most often be Outlook 2007, but these issues can crop up anywhere. Microsoft themselves doesn’t want to support Outlook 2007. Their official Xbox newsletters have a line at the top that says “Read this issue online if you can’t see the images or are using Outlook 2007.” That said you can usually get emails to look perfect in Outlook clients if you take the time and effort. There is however clients like Lotus Notes where you may have to sacrifice your design to the whims of client renderer.

The only real saving grace is that email is usually a fairly static medium, so you are not going to have to go around and update 500 pages and styles. If you do have dynamic email campaigns I recommend building and branding them dynamically with a server side language like php and then outputting the static files before sending them off to your deployment platform. Some platforms will also support dynamics builds. At the end of the day, if you stick to HTML principals that worked in 1996 and mix in a bit of basic CSS you are probably going to be okay. Happy coding and please never use these tips for regular web pages.

There’s too ways to create OFT files. One is to save the email from the Save As menu and select OFT under the Save as type: drop down. This means you already have the email in your inbox, which means mailing the html with a 3rd party program.

There’s an easier way to do this which will allow you to skip the step of sending yourself the email. The OFT process could even be handed off to the business people that need the OFT.

Top menu go to,

View / Toolbars / Web.

You should now have an input field at the top that says something like outlook:Inbox

Here you can type / paste any web address and it will load the page in Outlook. Once this is done, in the menu go to,

Actions / Send Web Page by E-mail

Now you will see the page in a new mail window. If the webpage was not to complex and created using tables, it should look okay. Pure css and more complex designs will not work at all and really shouldn’t even be considered for any email deployments. I’m a strong supporter of web standards, unfortunately some major email platforms are not.

The next step is to save the email as an OFT. Go to,

Giant windows bubble (AKA Office Button) / Save As

Select OFT, name the file and save.

You should now have an OFT file. You can test this by double clicking it which will open Outlook. You can now edit the text and send to other people. OFT files can be a cheap internal alternative to full blown email deployments. I would only recommend OFT files for small internal newsletters. OFT’s may not work properly on other email clients and are proprietary.

All web designer’s have faced the many hurtles of browser compatibility. Getting things to work on multiple browser versions and browser types can be a real pain, but this is child’s play compared to the ever changing world of html based email. I’m not going to talk about whether email should have ever been used as a medium to deliver rich content, there is plenty debate about that elsewhere. The fact of the matter is that html email is here, and it’s very popular.

For the past three years the number one hurtle for myself and the company I work at has been Microsoft’s web based email, Hotmail. This client ruthlessly tears apart your beautiful standards compliant html and leaves a broken mess behind. Everything from requiring inline styles everywhere to removing all your margins, this beast has not been fun. Microsoft has now released Live Mail which is replacing Hotmail and is slightly better, but it is a tiny step in the right direction. I should also add that we have very little problems with Yahoo mail, and in general very little problems with most modern stand alone mail clients now.

Recently this has all changed. There is a new big, bloated and terrible mail client in town, and of course it’s also by Microsoft, and that client is Outlook 2007. Up until now, previous versions of Outlook supported both html and Word, but with Outlook 2007 only word is supported. Microsoft says this move is to standardise on one platform or something along those lines. I always thought that we as an industry had standardized on the W3C Standards, where have I been?

How do we deal with this new client? Rewind backward ten plus years in web design and we find ourselves in 1996 with minimal CSS, hundreds of messy nested tables, and the mighty fix all spacer gif. For the most part I have managed to make my emails hold their integrity in Outlook 2007, although with much pain and suffering.

The other day I was working on an email newsletter when I found a very strange bug, or maybe it’s a feature, since every other broken or missing aspect of Outlook 2007 seems to be documented as a feature. Basically I needed 400 pixel wide rules to separate some teaser articles. In a normal world this would be done purely with CSS, but I have gotten into the habit of using spacers for everything in my newsletters now. Stretching spacer gif images with the html height and width attributes has been an old stand by for years that some of us like to call the “brute force method”. You can image my surprise when a pixel stretched to 400 pixels came out to be only 66 pixels wide. After much head scratching I decided to run some tests which I will share with you here.

Basically Outlook 2007 at the time of this writing does not stretch 1 x 1 gif images past 66 pixels. At first I thought maybe this was a blanket rule to all spacers to stop the use of large pixel spacing. Why they would do this I don’t know, but it made more sense then what my testing further showed.

I decided I would try to stretch a 2 x 2 pixel gif to 200 pixels, the result was 131 x 131 pixel sized square. Now I don’t know what kind of funky math Outlook 2007 is using, but it’s not anything I have ever seen ever seen from any browser or email client to date.

Next I decided to try a 10 x 10 pixel stretched to 200 x 200. This resulted in the correct size. Below are two screenshots, one of the html in Firefox, and one in Outlook 2007.

Firefox Browser screenshot
Everything looks as one would expect it to look. It should look like this in every browser and mail client ever to support inline images.

Outlook 2007 screenshot

My advice to anyone coding email newsletters with Outlook 2007, is to use larger sized spacer gifs, 10 x 10 px should probably do the trick. You can also squash these down to 1 x 1 px images in the html without problems. Happy coding.