How to Code HTML Email Newsletters

Originally published at: http://www.sitepoint.com/how-to-code-html-email-newsletters/

This article was first published in 2006, then re-edited in 2011 — and now it’s been re-re-edited in 2015.

HTML email newsletters have come a long way since this article was first published back in 2006. HTML email is still a very successful communications medium for both publishers and readers. Publishers can track rates for email opens, forwards, and clickthroughs, and measure reader interest in products and topics; readers are presented with information that’s laid out like a web page, in a way that’s more visually appealing, and much easier to scan and navigate, than plain text email.

Coding an HTML email is a fun, practical problem for programmers to solve. Unlike coding a web page, HTML emails need to display well on old email software — think Outlook or Mac Mail, as well as adapt to phone and tablet screens. I’ll show you how to create HTML emails that display well on any device, plus ideas to adapt your current HTML email code to display on phones and tablets.

This is actually the third revision of an article that was written and published on sitepoint.com in 2004, and includes new, up-to-date material that will help you ensure that your HTML email newsletters meet the requirements of today’s email clients.

HTML Email Fundamentals

The biggest pain when coding HTML email is that so many different software tools are available to read email, from desktop software such as Eudora, Outlook, AOL, Thunderbird, and Lotus Notes, to web-based email services such as Yahoo!, Hotmail, and Google Mail, to email apps on phones and tablets. The software used to render HTML for each email software tool determines what HTML and CSS code works and doesn’t work.

If you thought it was difficult to ensure the cross-browser compatibility of your web sites, be aware that this is a whole new game — each of these email software tools can display the same email in vastly different ways. And even when these tools do display an HTML email properly, accounting for variances in, for example, the widths at which readers size their windows when reading emails makes things even trickier.

Whether you choose to code your HTML email by hand (my personal preference) or to use an existing template, there are two fundamental concepts to keep in mind when creating HTML email:

  1. Use HTML tables to control the design layout and some presentation. You may be used to using pure CSS layouts for your web pages, but that approach just won’t hold up in an email environment.
  2. Use inline CSS to control other presentation elements within your email, such as background colors and fonts.

The quickest and easiest way to see how HTML tables and inline CSS interact within an HTML email is to download some templates from Campaign Monitor and MailChimp. When you open up one of these templates, you’ll notice a few things we’ll discuss in more detail later:

  • CSS style declarations appear below the body tag, not between the head tags.
  • No CSS shorthand is used: instead of using the abbreviated style rule font: 12px/16px Arial, Helvetica, you should instead break this shorthand into its individual properties: font-family, font-size, and line-height.
  • spans and divs are used sparingly to achieve specific effects, while HTML tables do the bulk of the layout work.
  • CSS style declarations are very basic, and do not make use of any CSS files.

My Code HTML Email site also has actual HTML emails I’ve downloaded and formatted so you can study to see how others created email.

Step 1: Use HTML Tables for Layout

That’s right: tables are back, big time! Web standards may have become the norm for coding pages for display in web browsers, but this isn’t the Web, baby. A few email software clients are light years behind the eight-ball in terms of CSS support, which means we must resort to using tables for layout if we really want our newsletters to display consistently for every reader (see the reading list at the end of this article for some excellent resources on CSS support in mail clients).

So put your standards-compliant best practices and lean markup skills aside: we’re about to get our hands dirty!

The first step in creating an HTML email is to decide what kind of layout you want to use. For newsletters, single column and two-column layouts work best, because they control the natural chaos that results when a large amount of content is pushed into such a small space as an email. Single column email designs also make it easy to display well on phones and tablets.

A single-column layout typically consists of:

  1. a header, containing a logo and some (or all) of the navigation links from the parent web site to reinforce the branding and provide familiarity for site visitors
  2. intra-email links to stories that appear further down in the email followed by the stories and content
  3. a footer at the bottom of the email, which often contains links that are identical to the top navigation, as well as instructions for unsubscribing

Two-column emails also use a header and footer. Like a two-column web page, they typically use a narrow, side column to house features and links to more information, while the wider column holds the body content of the email. To get a two-column email layout to display well on a phone or tablet requires some code-fu, as you’ll see later in this article.

Promotional emails follow similar rules but contain much less in the way of content and links. They often include one or two messages, and sometimes make use of one big image with small explanatory text and some links below the image.

All of these email layout possibilities can be created easily, using HTML tables to divide up the space into rows and columns. In fact, using HTML tables is the only way to achieve a layout that will render consistently across different mail clients.

No matter how your email is designed, it’s important to remember the most important content should appear at or near the top of the email, so it is visible immediately when a reader opens your email. The top left of an email message is often the first place people look when they open an email.

This is the approach that I use to create HTML emails:

  • For a two-column layout, create one table each for the header, the two center content columns, and the footer — that’s three tables in all. Wrap these tables into another container table. Use the same approach for single-column layouts, but give the content table one column. This approach is especially suitable if the design of your email contains images that are broken up over multiple table cells. Otherwise, a single table with td rows for its header (with colspan="2" if the design uses two columns), content, and footer should display fine in all but Lotus Notes email software.
  • Use the attributes within the table and td tags to control the table’s display. For example, setting border="0", valign="top", align="left" (or center, if that suits the design), cellpadding="0", cellspacing="0", and so on. This primarily helps older email clients to display the email in a (barely) acceptable way.
  • Even if the design of your email doesn’t include a border around your table, you might find it helpful during development to set border="1" to help with the debugging of any problems that arise with the internal alignment of tr and td tags. Change it back to border="0" for testing and production.

While this approach might offend purists who prefer to code using the latest standards, it is the only viable approach at this point. But the fact that we’re using tables for layout doesn’t mean we need to resort to old-school methods entirely. For example, no matter how poorly Lotus Notes displays HTML email, you should never have to resort to using the font tag. And while Outlook 2007’s HTML rendering engine is less than perfect, it does display basic HTML tables just fine.

There are some caveats, though; let’s take a look at styling our text next.

Continue reading this article on SitePoint

Can we insert script inside this HTML email content to make sure the readability of the email. Mostly emails sent to the customers are ignored vastly so to make sure that the email has been read by the customer, Is it possible to write some scripts along with the email content which in turn send back some flag to the server side when its opened/read by users?

Not a script, but this usually achieved by using image.

<img src="http://example.org/set-flag.php?mail-read=1" />

But that won’t work If user disable images.

I’m creating Email templates while reading this post :smile:, and I see there is Ink framework to create responsive email. I wonder if anyone has experience with it.

@venkateshsun email delivery services do this all the time, presumably as permanaj notes, using a fake image call (or a call to a real image but with querystring values appended).

@permanaj Ink sounds interesting, although using a 12 column grid for a 360 pixels wide phone screen seems like overkill. This sort of implied complexity, or switching from one mode to another, is why I prefer to code emails by hand. However, surely there is an audience for Ink who would find the results good enough or perfect. And success is determined by how it looks across email software clients, something you can test with MailChimp, other email delivery services, and setting up your own test email accounts.

It should be noted that for emails that are rendered/served up to the Apple iWatch - the watch renders the TEXT version, not the HTML version. Fun times.

We stopped coding HTML emails ourselves after we found a better solution. It’s nearly impossible to hand-code complex, responsive HTML emails which really work in all clients.
First we worked with freelancers (oDesk) and now, happily, we use https://responsive.email and do it in our IT department again

@steve_web That sounds really interesting, iWatch renders the text email, thanks for sharing for everyone.

Jessica_Nordman From what I’ve seen, the only truly difficult emails to convert to a responsive design are 2+ multi-column and possibly catalog emails (with grids). However, even catalog emails could be coded to degrade to single column somewhat easily (e.g. instead of each cell in a TD put them into a nested table and use @media to set the width of each table). It would be interesting and useful to know exactly what type of email didn’t work for you with hand coding.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.