Email Development Best Practices

Original article URL:

https://www.emailonacid.com/blog/article/email-development/email-development-best-practices-2/

Email development can be a daunting task. Many new email developers, or web developers who are new to email, find that the complex and multi-layered email client ecosystem causes endless headaches; a fix for one client breaks their email in three others, or a simple float functions in only half of the email clients available.

The best practices that we outline below cover both email design and email development. Keeping these best practices in mind can save you hours of hair pulling down the road.

Even with these best practices, don’t forget to test your email. Finicky email clients are just one of the many reasons why you should test your email code every time. With Email on Acid, you can see what your design will look like in more than 70 clients and devices.

Email Design

Use Single Column Design

Keep the email design simple to make life easy! A single column design is sufficient for most emails and will help the design look good on mobile devices. It’s also easier for your readers to scan a single column of material.

Set 600px As the Default Width

We recommend that you keep your email’s maximum width close to 600px. This width should give you plenty of space for content and will fit nicely on most web and desktop clients. You can scale it down to fit better on mobile screens using media queries or fluid design (see below).

Keep Mobile Users in Mind

With the rise in popularity of mobile devices, some email designers have embraced “mobile first” design. This means that they design the email with mobile clients primarily in mind, and then make sure it also looks good on desktop. By putting mobile users first, designers hope to increase engagement and click-throughs on mobile devices. We recommend this approach especially for simpler emails like password resets, transactional emails and account updates.

Every Email Client Is Different

When designing an email, keep in mind that it’s going to be very difficult to achieve “pixel perfection” on every single client. Instead, try to achieve an email that maintains your branding while being easy to read (and click) on all email clients.

The only way to know how your email will look across the multiple clients is to test it. With a platform like Email on Acid, you can view your email in more than 70 email clients and devices, so you know how your email will look before you hit “send.”

Plan for Missing or Blocked Images

Some clients will block images by default, and some users will change their settings to block images so that they can use less data. If you rely on images to communicate your message, your subscribers may miss out if images aren’t downloaded. This is why it’s important to include descriptive alt text for your images and style the alt text to improve its appearance.

Use Email-Safe Fonts

If you use Google Fonts, you may find that many clients don’t support them. For this reason, it’s important to have a good fallback font. Your fallback font ensures your design still looks good without custom web fonts.

You’ll also want to make sure that you use a font-stack compatible with Outlook. One of the many quirks of Outlook is that an unrecognized font in the stack will cause it to fall back to Times New Roman. You can address this annoying bug using one of these four fixes.

Some of the fonts that are supported universally include:

• Arial
• Arial Black
• Comic Sans MS
• Courier New
• Georgia
• Impact
• Times New Roman
• Trebuchet MS
• Verdana
• Σψμβολ2 (Symbol)
• Webdings

MailChimp also has an excellent list of email-safe fonts.

Avoid Image-Only Emails

If a subscriber has turned on image blocking, your whole message may be lost. If you must use text in an image, use styled alt text to make sure your message gets across if the image doesn’t load.

Image-based emails are also very hard on your recipients’ data plans and can be very difficult for the visually impaired. Use HTML text where possible, instead.

Don’t Forget to Add an Unsubscribe Link!

…And don’t try to hide it. You don’t want to email people who aren’t interested in reading your emails. It’s also illegal to leave an unsubscribe link out of a commercial email.

The unsubscribe usually appears in or below the footer. If you want to go for extra credit, set up a preference center, which allows subscribers to select what type of emails they receive, or how often they receive them. This can help reduce the number of unsubscribes you see.

Email Development

HTML

Use Tables When Possible

Forget divs and floats. While it may seem like you’re coding in the dark ages of the internet, tables are the most reliable way to achieve a consistent layout. They also allow you to replicate something that many email clients otherwise don’t allow: floats (okay, not really CSS floats). With tables, you can take advantage of the align attribute, which was the predecessor of modern CSS floats.

When using align=”left”, tables will stack on top of each other on smaller screens. This technique is the basis of responsive and fluid design. It works like this: You have two tables that are each 300px wide with align=”left” inside the same container. If the screen is 600 or more pixels wide (as it would be for most desktop clients) then the tables will appear side by side. If the screen is only 400px wide, then the two tables will stack on top of each other. Nested tables are totally safe, so feel free to nest away.

You can also use colspan and rowspan, as long as you count your columns and rows carefully.

However, watch out for empty TDs, as some email clients don’t handle these as you’d expect. Usually this issue can be fixed by adding ” ” or non-breaking space character. You can control the size of this character using CSS, so it doesn’t mess with your layout.

Know Your Framework

There are two popular approaches to coding email. The most popular framework is called “responsive.” The basis of responsive emails is to start with a 100%-width table (to which you can apply styles that will affect the whole email) and then floating a fixed-width table in the center of this wrapper (using align=”center”). If you use media queries, you can adapt the width to various screen sizes. Our free responsive template is a great example of this coding technique.

The other popular framework is called hybrid fluid or “spongy” design. With the hybrid technique, you set container tables to width=”100%” and constrain the container tables with a max-width style. When a hybrid design displays on screens wider than the max-width, the table will reach its max. On a smaller screen, the table will naturally fill the available space.

The “hybrid” part of this technique is that you must surround each table with a conditional table visible only to Outlook. The hybrid table has a fixed width, which solves the main problem with fluid design: Outlook ignores max-width statements.

The main advantage of the hybrid or fluid technique is that it works pretty much everywhere, regardless of whether the client supports embedded styles or media queries. For more on hybrid fluid design, check out our primer. We also have a few free hybrid fluid templates.

Make Sure You Include Comments in Your Code

Including comments in your code will make editing templates easier. Because email development is full of hacks and fixes for client quirks, it can be helpful to note why you added a particular style or element.

Encode Special Characters

If your email service provider (ESP) uses a different kind of encoding from the kind you selected for your email, it may cause your special characters (like ©) to appear incorrectly, often as a black square or a diamond. This can affect quotation marks and apostrophes, as well. To avoid this problem, use a character encoder, or take advantage of the one that is included with the Email on Acid Email Editor.

GET ACCESS!

Keep Email File Size Under 100kb

There are a couple good reasons to keep your email under 100kb. First, it will pass through more spam filters by staying light. Keeping your email under 102kb will also prevent Gmail from “clipping” your email.

To keep your email under the limit, consider removing redundant or unused styles, moving some of the content of the email to a landing page, or removing any unnecessary characters from your code. Just make sure to test any changes before the final send!

Code for High DPI Displays

High DPI displays can often cause issues when scaling email designs. This is because it will scale certain parts of the email (height, width, font-size etc. that are coded in px), but not other parts. To make sure your whole email scales properly, just follow the steps in our coding for DPI scaling in Outlook blog post.

Include Preheader Text

In most inboxes, preheader text displays after the email subject line. This text is easy to code and can make a huge difference in open rates. Just make sure you don’t hard-code “default” preheader text into your template.

If you include hard coded preheader text (usually in a field that can be modified), you may forget to customize it and you’ll send out an email with preheader text like, “PREHEADER TEXT HERE.” What a faux pas!

Instead, just include the “default” preheader text as an HTML comment. This way, other marketers and developers you work with will know why that code exists, but recipients won’t see it if you forget to customize.

Avoid Javascript, Flash, Forms and other Complex CSS/HTML

Javascript and Flash are completely unsupported in email clients, so don’t use them at all. Newer code, such as HTML5 and CSS3 have limited support, but are sometimes possible (and fun!) to use. These enhancements should be used with caution. As always, test thoroughly when using any advanced code.

Use Cellpadding for Spacing

Cellpadding provides reliable spacing across all email clients. If you need spacing only on one side of an image or container, you may want to use another spacing technique. Check out our blog post on spacing techniques in email for more info.

Test Your Email!

Email coding is hard! Every email client has different quirks when it comes to rendering code. Outlook for desktop (2007, 2010, 2013 and 2016) can be especially challenging. The only way to know your email will look great everywhere is to test it. Email on Acid can help you test by generating screenshots of your email in more than 70 email devices and clients – all in less than 30 seconds.

Images

Make Email Images Retina Ready

Many devices now include “retina” displays. This means that the devices have more physical pixels than their CSS dimensions would otherwise indicate. For example, a 10px-wide image might use 20 or more physical pixels to display. By using extra-large images, you can make sure the images appear extra crisp on these displays. For more on this technique, read our article about retina images in email and fluid retina images for email.

Use Absolute Addresses for Images

You may be using local image references for your testing, but when you do your final send absolute image references are a must!

Get Rid of Strange Spacing Around an Image

This is a doctype issue. Use display:block and it will usually remove this extra spacing.

Don’t Use Image Maps

If you need to connect one image to multiple locations, you’re going to have to slice it. Put each slice in its own table cell, and then link the images. This can cause all kinds of havoc trying to get the slices to line up perfectly, so only do this as a last resort.

Take Some Extra Time with Background Images

Outlook can’t handle the background attribute or backgrounds set through CSS, so you’ll have to use VML to get backgrounds working in Outlook. Even with this workaround, Outlook can still be finicky. If you’re having a hard time, try using Stig’s button and background generators.

CSS

Use Inline Styles

Some Gmail clients, like Gmail Android App for Non-Gmail Accounts (GANGA), still don’t support embedded styles. In addition to this, there are a few smaller email clients like Yandex and Telstra that still require inline styles.

To do this, you can code with classes and IDs and then make use of a CSS inliner. Email on Acid has an inliner that you can use from any email test, or from within the Email Editor.

Avoid Shorthand CSS When Possible

If you see problems with a client interpreting your CSS, check to make sure you’re not using a shorthand declaration. For example, “margin-top: 5px” may work where “margin: 5px 0 0 0;” does not. It’s important to also avoid three-digit hex codes. Some clients will not recognize these, so you’ll want to make sure you always use the full six-digit hex code.

Get Used to !important

If you are a web developer, you may have been trained to avoid !important at all costs. When coding email, though, you’ll find this declaration can be invaluable. You can use it to override styles that the email client adds or modifies (especially web clients). You’ll also get a lot of use out of !important when writing media queries, where this declaration will let you override a default style with a mobile-specific one.

Get Comfortable with Media Queries

Media queries are commonly used to create custom styles for different clients or screen sizes. The basic format of a media query for email is:

@media only screen and (max-device-width: 640px){ styles here }

This will cause the styles contained in the query to trigger only on screens of 640px or smaller. “Min-device-width” would do the opposite, triggering on screens of 640px or larger.

Media queries are most often used to control font sizes, image sizes, and to make some tables become 100% width so that they will fill a mobile screen. You can also use media queries to hide content that isn’t necessary for mobile users. Just make sure that you use !important on styles within the media query, so that they will overwrite existing styles. Check out this article for more information on on using media queries in HTML email.

The Most Important Email Practice: Testing

Even if you’re using these email best practices, the most important part of any email process is testing. There’s no point spending the time making sure your emails look great on different devices if you don’t test them. When you use Email on Acid you can see how your email looks in more than 70 devices, giving you the confidence to hit “send.”