Let the platform do the work
SugarClubContact+1 (877) 842-7276

Using CSS in Email Templates

Even the most experienced web designers will find that using CSS in an email template can be tricky and downright frustrating. While most major web browsers try to respect certain standards to ensure that web pages appear the way their designers intend, the email clients that will render an email template are far less consistent. Here are ten important best practices for styling HTML email messages from code view.

Overview

Most organizations choose to send commercial email messages in HTML format opposed to plain text because HTML allows for flexibility in custom design elements such as fonts, colors, images, and layout components. CSS language is frequently used to accommodate advanced styling in web design, but even the most experienced web designers will find that using CSS in an email template can be difficult. While most major web browsers try to respect certain standards to ensure that web pages appear the way their designers intend, the email clients that will render an email template are far less consistent.

The following article recommends best practices for styling HTML email messages with CSS from code view. Be sure to check out the Additional Resources section at the end of this article for links to helpful online tools.

When sending emails individually via the Emails module, to groups of recipients via the Campaigns module, or by automatic trigger via Admin > Workflows, email templates are responsible for what the message will look like to the recipients. Sugar's email template composer features a WYSIWYG (pronounced wiz-ee-wig: What You See Is What You Get) interface that enables users to create HTML emails using familiar formatting tools from a design toolbar. For more granular control of the code, users can toggle from this design view to a code view. The code view button is one of the first options on the design toolbar, represented by the letters "HTML":

Prerequisites

  • Basic knowledge of HTML and CSS is required.
  • You must have access to the Emails module to create regular email templates.
  • You must have access to the Campaigns module to create and send campaign email templates.
  • You must have administrator access in order to create workflow email templates and workflows.

For more information on these items, please refer to the Role Management, Campaigns, Emails, and Workflow Management documentation.

Restrictions and Best Practices

Here are ten important best practices for styling HTML email messages from code view.

Use Inline CSS

Avoid external style sheets or style declarations between the <head> tags. Instead, use inline CSS. Some email clients strip out <head> and <style> tags from emails, and external style sheets are largely ignored. Therefore, every HTML element must be styled using inline CSS by virtue of the "style=" declaration. Inline CSS is a method of using CSS within your HTML content instead of storing it in an external CSS file. For example, each paragraph of text will have an independent style declaration, such as:

<p style="color:#ffffff;font-family:arial,'sans-serif';">This text is white and Arial.</p>

This is the most basic and important rule of CSS styling in emails, but it is also tedious and repetitive. Thankfully, there are several free tools available online to convert traditionally styled HTML content to inline styles; we have included links to some of these in the Additional Resources section below.

Declare Font Styles Near the Text

Declare all font styles within the element closest to the words you are styling. This will often be inside the <p> tags. If you want hyperlinks to display in a style other than the default blue underlined style, you must use CSS to declare the preferred style inside the <a> tag.

Use Nested Tables

Avoid layout-specific CSS in the <body> tag. Instead, create nested tables to control layout design. While tables are generally reserved for presenting tabular data in web layouts, HTML design for email requires the use of tables for just about everything when it comes to layout. Ignore what you learned about the evil HTML table and get ready to nest tables inside of tables inside of even more tables. HTML table attributes (instead of CSS) should be leveraged for table design and layout purposes: width, height, bgcolor, align, cellpadding, cellspacing, and border. Limit inline CSS table styles to padding, width, and max-width.

Use Tables to Position Images

Avoid using CSS inside the <img> tag to position images. Instead, position images using table cells. There are many rules for using images in HTML email templates, but making sure images appear where you intend them to appear will depend on properly nested tables. The only CSS you may need to declare inside the <img> tag is style="display:block;", which will eliminate unwanted gaps between stacked images in some email clients. 

Use Absolute Paths for Images

Always use full paths for image links, never relative paths. Unlike traditional web pages that are often stored on a shared file server, HTML email content will be rendered in remote email clients, thereby losing any relationship to local file directories. For this reason, relative link paths like /graphics/image.png cannot be used. Instead, write out the entire absolute path to the image. Absolute paths will include the website URL before the specific directory location of the image file (e.g. http://www.domainname.com/graphics/image.png).

Note: Unfortunately, not even absolute paths will protect your images from email clients that block the display of images in incoming emails. That is why it is essential to also include a descriptive HTML "alt" attribute inside design-centric image tags. The text defined in this attribute will be displayed for the viewer even when images are blocked by their email client.

Do Not Use Background Images

Avoid background images. Instead, embed HTML images directly on the page. It is true that some email clients will respect the HTML "background" attributes in the body tag and others may allow the attribute in table cells. However, support for background images is so inconsistent that it is best practice to avoid using background images altogether. If your email design is background-image dependent, it is time to reconsider the design.

Design Responsively

Desktop email client usage is diminishing as tablets and smartphones take over. In fact, more than half of all emails opened in 2013 were rendered in a mobile client, and checking email was found to be the most popular activity on smartphones. With such diversity of device size, it is essential to design HTML emails using responsive web design techniques that will adjust content to the screen size of the reader's device. One of the easiest ways to create responsive content is to use only percentage widths (opposed to fixed pixel widths) for tables, but we have included links to more complete tutorials in the Additional Resources section below.

Send in Plain Text, Too

Because it is virtually impossible to create an HTML email that will render identically in every email client, satisfy the most finicky clients with a plain-text alternative to your message. If the recipient has specified that they only want to receive plain-text email or if the recipient's email client rejects your HTML version, the plain-text version will be delivered instead. A plain-text message will contain no images or text formatting. It is not the prettiest option, but it will at least ensure that your message is reaching the widest audience possible. Sugar's email template wizard allows you to craft an entirely plain-text message or to include a plain-text alternative with your more robust HTML email campaign. For more information on creating HTML and plain-text email templates in Sugar, please refer to the Emails documentation.

Test, Test, Test

No matter how many rules you follow, you will probably never get an email message to render identically in all email clients and devices. That is why thorough testing of your message over multiple platforms is essential. Pay particular attention to the email clients that are most popular overall (highest email client market share) and the ones that are popular with your audience. Consider using an email analysis tool or create multiple email accounts for receiving test messages. Remember that any change to the template to accommodate one client may break the design in another client.

Obey the Law

Always abide by CAN-SPAM regulations (or the relevant laws in your country). All commercial email messages sent to or from the United States must comply with the law known as the CAN-SPAM Act. Compliance guidelines are exhaustively outlined on the FTC's Bureau of Consumer Protection website. Some (but not all) of the required message elements to include in your business emails are:

  • A message identifying the correspondence as an advertisement
  • Your valid physical postal address
  • A clear and conspicuous method to opt out of getting email from you in the future

In addition to the CAN-SPAM law, you must also comply with the anti-spam laws of the countries in which your recipients live. For example, if your email subscriber list contains recipients in both the US and Canada, you must check the Canadian spam laws to confirm that your message and sending practices are also compliant for your Canadian audience.

Failure to comply with these laws could result in steep fines and sending penalties including denylisting of your sending domain. For more information about the CAN-SPAM Act and the spam laws in other countries, please refer to the Additional Resources section below.

Additional Resources