ReportMail Blog and Announcements

Coding HTML emails

Posted on Monday, February 09, 2009

Coding for email is very different from how you would code for the web; email clients are not web browsers.

Some of them have rendering engines from text based applications like MS Word. As such you can’t include certain elements in emails and you have to code in a specific way.

We’ve been designing and building emails for over 5 years and we have seen all kinds of rendering issues and resolved them, so why not let us design your email. However, if you’re up for a challenge here are some hints and tips to guide you along the way. Happy coding!

The overall width should be no more than 600 pixels

Most websites are built to fit in 800x600 pixel resolution screens or maybe even 1024x768.

But that won’t work when you come to build an email. Most recipients will be looking at your email through their “preview pane” which is usually a small portion of their available screen (see screenshot below).

Above is a screenshot of an HTML email in Microsoft Outlook 2007’s preview pane. Outlook is maximised to full screen (1024x768 pixels), but you will see, the preview pane is only about 440 pixels wide. In AOL 9, the “preview pane” is only about 194 pixels wide, then when you click “Full View,” it typically opens up a window that’s about 540 pixels or so. This is why you shouldn’t design emails to be larger than 600 pixels in width.

Simple layouts and table structure work best

Email clients all react differently to HTML, some render it perfectly and some mangle it beyond recognition! You need to keep your email designs simple. Avoid complicated layouts, too many embedded tables, and tables with too many rows and columns. A simple two column table with a row across the top should do the job just fine.

There are lots of email clients that don’t render email very well when you code tables with colspans (table cells that “span” across multiple columns) in them. One application that’s particularly hard to render in when it comes to tables is Lotus Notes.

If you’re coding an email and find the tables are getting complex, and you’re having to use too many “COLSPANS,” you might think about cutting it up into separate tables. For instance, you can use separate tables for the header, body, then footer of your email. It is always better to use more “simple” tables, than one large “complex” table.

Special considerations for web email clients (like Gmail and Yahoo!)

A lot of your contacts will check emails in their web browser (especially if you do any b2c emailing), such as Yahoo! Mail or Gmail. Since they’re viewing email in browsers, there are some things you need to know when you code your HTML:

They will strip out your <HTML> and <HEAD> and <BODY> tags, in order to keep your code from interfering with their web pages. That means...

Any background colours specified in the <BODY> tag will be lost. So wrap your entire email inside a larger, 100% wide table, and set a background colour to that table.
Any CSS that you place inside the <HEAD> tags will be lost. So don’t try to link to external CSS files. Use embedded CSS instead, and make sure it’s always below the tag.
Some web based email clients are starting to strip even the most basic CSS, even if it’s embedded below the <BODY> tag (like we described above). This is because they don’t want any of your CSS interfering with their CSS, bear that in mind, and test your campaign thoroughly before sending.

Tip: you can use our campaign preview to get screenshots of how your email will render in 32 of the most common email clients including hand held devices.

CSS in email

CSS (Cascading Style Sheets) are great for building websites, but don’t rely on it for HTML email design. For example, DIVs won’t work in some clients. And definitely don’t use CSS positioning.

You’ll have to rely on for your layouts in HTML email, and only use CSS for simple font formatting and colours. Always code your CSS so that if someone took it away, your design and content would still render correctly.

Before you send your email, delete the CSS and see what it looks like. Did you have small text that is now extra large, and is now moving your table structure?

CSS is especially difficult to code correctly if you’re using a WYSIWYG to build your email because WYSIWYGs insert CSS and DIVs by default. We use one of the webs leading WYSIWYGs which generates very clean code but we would still recommend and structural changes to an email are made using a programme like Dreamweaver. WYSIWYGs should really only be used to update an existing template with new copy.

Programmes that won’t work in email - Flash, JavaScript etc

You can deliver emails with almost any programme embedded in them, but most recipients won’t be able to view them. Not unless they’re using an email program that uses a browser to render their HTML email. Microsoft Outlook 2003 was a program that used IE 6 to render HTML. Microsoft Outlook 2007 no longer uses IE to render email (it uses MS Word), so Flash won’t play. Most anti-virus applications block the code used to embed Flash movies, and they block JavaScript, ActiveX, and even music files. That kind of technology has been used in the past to spread viruses, so it’s blocked now by most ISPs.

Background colours

Earlier in this article we told you that browser-based email services (like Yahoo!Mail and Gmail) strip out the <HTML> and <HEAD> and <BODY> this needs to be remembered when coding your background colours. You normally specify that in your tag, but you can’t rely on that with email. You need to create a 100% wide table wrap around the email. Set the background colour in that table, and use some CELLPADDING if it’s needed.

When coding image tags in HTML email...

Do this:
<img alt=" src="http://www.server.co.uk/email/images/imagename.gif”/>

Not this:
<img alt="src="/Portals/2/”images/name_of_image.gif”/>

Note: If you use ReportMail’s WYSIWYG, we host your images on our server for you (it’s free). So you don’t need to FTP files anywhere. Always make sure that images have a full path and don’t rely on a WYSIWYG to do it automatically.

Common errors to avoid when coding an email

Here are some of the most common mistakes people make when coding HTML emails:

Not coding “absolute paths” to images. Remember, attaching graphics and using “relative paths” won’t work. You need to host the images on a server, and then link to them in your code.
Using JavaScript, or ActiveX, or embedding movies. It’s not that you can’t send them; it’s that they don’t render.
Making the design too complicated. Designing HTML email isn’t the same as designing web pages. You can’t have the CSS-positioning, DIVs, DHTML, and embedded tables like you can in web pages.
Not including an opt-out link. It’s illegal not to allow an opted in contact to opt out. If the contact didn’t opt in in the first place then you shouldn’t be emailing them.
Linking to an externally hosted CSS file. You usually put CSS code in between the <HEAD> tags of web pages, but browser based email applications (like Yahoo and Gmail) strip <BODY> and <HEAD> tags from HTML email. Embed your CSS below the <BODY> tag if you are going to use it.
Using a WYSIWYG to “build” your email. WYSIWYGs will add unnecessary code, try using Dreamweaver instead.
Forgetting to test. When you send email, you need to test it in as many email clients as you can. Then try testing on different operating systems. If the design is simple you won’t have to test as much. But you should always send at least a few campaigns to yourself before sending it out to your entire database.
Sending 1 big image as an HTML email, this will look like spam to an ISP. And since most email programs block images by default, your recipients will see a blank email when or indeed if they open your email. Many spam filters will block your email if you don’t have a good HTML to image ratio.