This site uses cookies. Not nice tasty oven fresh cookies, with gooey chocolate, or with raisins and oatmeal if you want to pretend to be healthy. But little snippets of code to improve your experience. If you continue, it is assumed you're happy to receive all cookies from the website.
More about cookies

HTML Emails

Information and thoughts on how to build a responsive HTML email.

21 February 2019

Email design and development requires some retrospective development skills and a willingness to accommodate practices that can seem at odds with modern web development best practice.

If you're a web developer, UX / UI developer, front-end developer, it's inevitable that developing an HTML email will be at the very least an occasional job that comes your way. Sometimes it can be the vast majority of the work you are involved in.

Poorly handled and delivered email can have a major detrimental effect on a brand's identity. Recently introduced GDPR guidelines are the result of an in house cottage industry for many organisations that have seen users swamped with sub standard marketing material. For many developers, the email offering feels like the poor cousin of web development, but it is neglected at an organisation's peril.

Email clients have been slower to pick up on modern, common, responsive design standards, expected of websites, and apps, and as a result coding HTML emails has continued to adhere largely to web 1.0 best practice. Many of the email development resources mentioned here still make use of what can be considered a WYSIWYG (What you see is what you get) GUI (graphical user interface) based editor. And HTML emails are still dependent upon tables for delivering their layout, largely omitting the more modern layout tags, and even the staple div tag.

In fact, email development is a much more expansive endeavour. With the introduction of mobile devices, and more and more email clients, we have even more possible combinations of device, OS, and client to deal with when building HTML email, than with web.

Email clients

Take a look at CanIuse.com browser comparison table, there are 18 browsers in total with about 90% of traffic using one of five browsers (as at February 2018).

Email has significantly more client options, although for the same time period just short of 100% of email clients can be divided between 10 clients.

One thing be clearly identified from this though, that email, like web, is moving away from the classic desktop device model, towards having a greater market share based in mobile, and portable devices. Email has taken on a portability that was traditionally reserved for sms messaging.

Scalable v Fluid v Responsive design

There are three accepted principles of email design, these are briefly outlined below.

Scalable email design
Scalable email design often consists of a few different components: a simple layout that is often a single column that's scalable for all sizes; large, attention-grabbing text; and large, clickable call-to-action buttons. Use this format if you're looking to change things up with a minimal amount of coding effort.
Fluid email design
Fluid email design makes use of percentage-based sizing to automatically adjust the width of tables and images to the device's screen size. Use this format if you're not afraid of a bit of extra whitespace around the edges of your content.
Responsive email design
Responsive email designs are all about providing content that is customized for your user's chosen device. With responsive design, you can send email templates which can change depending on what screen size they are viewed. These emails will always render correctly regardless of the device it's viewed on.

Content and type of email

It's worth considering what kind of email is being sent out. The content of the email will directly affect its nature and what is appropriate to send.

Marketing email

A lot of email service providers (ESPs) specialize in marketing and promotional emails. They provide full solutions for managing subscribers, working with email templates, running bulk email campaigns and reporting. These emails are best considered largely as an invitation to visit a page or site.

These are the emails that one would expect to make the most use of HTML and CSS functionality to deliver pleasing content in an attempt to boost web-traffic, and / or sales from a site.

Transactional email

Transactional email includes receipts, alerts, welcome emails, password resets and so on, and it is typically implemented with development tools and APIs from with-in a cms or back-end build. These tools are more API-focused.

An alternative to using a service is to roll your own email server. The downside of this is that it's up to you to set up and configure it and to understand the technical details of sending email, implementing tracking and unsubscribing, and getting email delivered to inboxes.

These are far more functional emails, used to state information, and thus stick closely to the subject topic. While these can make use of HTML and CSS resources, the functionality of the message is the most important feature and these usually have enough branding to be recognisable, but are largely text based.

Life-cycle email
Life-cycle and behaviour-based email services help with onboarding, engagement and more. A lot of ESPs focused on marketing also offer this service. These sit some-where in the middle. A combination of an invitation and transactional these can be considered more as reminders to action something, rather than a passive invitation or a purely functional transactional email.

Building an HTML email

Most designs will combine several aspects of the three principles. But as a general rule the following principles should be adhered to.

  • Branding - ensure first and foremost that the branding of your email matches the branding of your other resources, whether they be web based, print or digital media.
  • 600 pixel width - while mostly this is not a static rule, and more an outlook legacy issue to do with window sizes on 1024px screens, it is a good idea to keep your email content width to now more than 640px for consistency across clients and devices.
  • Height - again there is no hard and fast rule, but the preview pane for "above the fold" text is usually between 300 and 500 pixels high, but of course, your email can be as high and contain as much content as needed to convey your message, but you also need to be clear who the sender is, and start the message in that space.
  • Concise - Think about your type of email and its content, often less is more.

Ultimately open rates of emails are very low, there's no point in using an email to convey a long message, rather it should be considered an invitation to, or direction to a website. Even if the message is vitally informative or important, don't use an email to deliver it, use it as an invitation.

At the same time, a poorly developed email, or no email at all, is a waste of a valuable resource at best, but can also have a detrimental effect on your organisation's reputation and branding in in-effectually delivered.

Surfer Dude Studios template

The template used by Surfer Dude Studios can be viewed and downloaded from our github repository, or as an html file from here.

As stated, there are four key points to building a responsive email, and Surfer Dude Studios solutions to these issues are listed below.

  • Branding - three main branding colurs (Deep Koamaru, Night rider, White) are used with the background one of the secondary (Turquoise). The logo is clearly visable at the top of the email and the font family matches the website, as does the imagery.
  • 600 pixel width - the email uses a maximum width of 600 pixels for the content area. The back ground and header background do extend to full width, but the readable content remains centred in a 600px wide space.
  • Height - the main imagery scales, so that the logo takes up full width in mobile, with (ideally) the main image not displaying. Support fo this feature can vary, but more on this later. In the best circumstances the introductory heading, and start of the email always appear first.
  • Concise - short sections, with prominant links back to the website, rather than lost of content, the biggest section, the introductory text, is only three paragraphs.

Inline CSS

Some clients (most notably Gmail until recently) will strip any CSS that isn't inlined, that is styling and layout content written in the head section of an HTML file, or contained in a CSS file, will be removed. It is better to use inline styling, that is using the style attribute, to define the style of a DOM object. For example;

<td align="left" style="font-family:'Muli',Helvetica,Arial,sans-serif; font-size:16px; line-height:18px; color:#333333;" valign="top" >

There are a couple of development options here:

  • write CSS inline as you go,
  • use a web-based CSS inliner (eg. https://putsmail.com/inliner),
  • use a programmatic CSS inliner,
  • let your ESP handle the inlining for you (if it supports it).

Validating an HTML email

This is where significant effort and investment in your email has to be made. As stated the plethora of devices, operating systems, and email clients, means that the variety of ways that emails are handled is enormous. An example would be the variety of support for the CSS display: none; property. As previously stated support for this varies significantly, and an email developer or designer will have to have an element of flexibility in their design to allow the email to function.

No single developer or designer can be expected to be able to cover all possible combinations of device, OS, and client. This is not to say that viewing the email on as many devices as possible is not an option, putsmail is a free service from litmus that allows users to test send emails to up to ten email addresses at a time. The main email marketing platforms (eg. Salesforce Marketing Cloud (Formerly Exact Target), and Campaign monitor), have native test send features. It is always a good idea to test on as many actual devices as possible.

However this will never sufficiently cover the possibilities, so budget dependant, it is always a good idea to use a testing and validation tool like Litmus, or Email on acid to validate and test your email before sending.

Sending your email

After vigorously testing your email, you will want to send it. While it is possible to simply paste your html content into an email and send it, most organisations will make use of a delivery platform (eg. the previously mentioned Salesforce Marketing Cloud (Formerly Exact Target), and Campaign monitor), this is for several reasons.

  • Timed sends - platforms can be set to deliver emails at a set date and time from a variety of email servers meaning there is no disparity in the times that clients receive emails,
  • Recipient management - receiver information can be maintained, secured, and controlled, allowing email content to be targeted, and users to choose how they receive, and how many emails they receive,
  • Analytics - platforms will record opens, unsubscribes, failed deliveries etc, and often allow for A/B testing to improve email performance,
  • Plain text and web versions - automated generation of plain text, and web versions for recipients who seek it,

Further reading

Additional information can be found at the links below.