When I started working on HTML emails I tried Googling for CSS and HTML email and it seemed the theme of the articles was to warn designers not to use CSS in email because it is not widely supported by email clients. Instead, they recommend using the <font> tag that was deprecated in 1999.

So I think these other articles are just outdated. There was a time when CSS and email would have been a naive combo. Today, I have a hard time imagining anyone well-versed in CSS recommending <font> tags. Since I have been using CSS in HTML emails for a while now, I thought I would put together some more current information from my current practices. Perhaps others also need to create HTML emails, but cringe at the site of <font> tags.

Why HTML?

First, it should be noted that there are those who question the value of receiving email as anything other than text-only in fixed-width Courier with lines 80 characters wide. I suspect their frustration comes not from the fact that someone else selected the font, but that the capabilities of HTML email are frequently abused by spammers or used inappropriately by legitimate opt-in content providers.

Despite HTML’s misuse in email, the presentation of information is strongly linked to the reader’s ability to absorb, comprehend, and react to it. HTML combined with CSS can be used to allow creative and effective presentation via email, while degrading gracefully on the various presentation technologies the email may encounter.

The enlightened will realize that concise, useful, enjoyable content (that means text) is why recipients are interested in your email. If your content isn’t interesting on its own, then your readers probably aren’t interested in receiving it. Text is not intrinsically boring. Use CSS to clarify and enhance. To use a metaphor, the cake is more important than the frosting. Use the frosting to enhance the cake. But make sure they get the cake, even if the frosting gets a little smooshed.

Is CSS Supported?

If HTML is supported, then yes. In the beginning (by that, I mean when HTML support first appeared email clients), CSS was a fairly new and sparsely supported. Today, most modern HTML-capable email clients¹ use the HTML rendering engine provided by the client’s operating system, all of which support CSS to some degree. Mobile devices generally degrade HTML to something their display is capable of displaying. Blackberries, for instance, are able to make use of heading tags and lists, but disregard CSS information.

Keep in mind that some readers may block HTML and/or images from emails. Newer versions of Outlook and some web-based email clients allow users to block images and/or HTML in email as both can apparently be used to breach the security of Microsoft products. Always include a plain text multipart-alternative for those that can’t deal with HTML for whatever reason. (Outlook, btw, includes a Plain Text alternative version for every HTML email it sends. That’s great accept it creates the plain text version by computer-guessing based on the HTML version. It’s usually quite ugly, certainly no Markdown. There is no way to change it. Just FYI.)

Determining Factors

The way I use CSS in email is much different than how I use it for web sites. The differences in my current approach stem largely from two concepts:

• The intrinsic differences between emails and web pages.


• The problems raised by the web-based email client.

Emails are Not Web Pages

There are many ways in which emails are not web pages, ranging from technical aspects to user experience, but the following technical differences determine my current CSS approach.

Web pages are based on a server and accessed from a remote location. They exist as single components of a larger family of pages. They are hopefully revised over time to keep content fresh.

Emails are atomic. They live their lives as complete entities, detached from a set location and frequently changing location several times. Once they have been sent, you no longer have access to them for changes, but other people do.

A much wider range of users and technologies create and manipulate emails. Some research indicates the most common email client, Outlook, has around a 40% share, with web-based email clients having a 20-30% market share. This is drastically different than Internet Explorer’s near 90% share of among web browsers. Simplicity and broader testing are required if design stability is a priority.

About External Links in Emails

So, since emails are atomic, theoretically I feel the email should contain all the data needed to display properly. In practice however, while I feel CSS should always be embedded in the email rather than linked to a remote style-sheet (AOL Mail doesn’t allow external stylesheets, btw), I still prefer to use external links for images. You can also refernce images attached to the email, but that doesn’t always degrade well when the email is forwarded. And, if attached to the email, the images will show up as useless attachments for recipients using non-HTML-capable clients.

Broken Images = Bad

The decision to use externally linked images also means that if readers access the email while offline, they may see broken images. Broken images are a bad thing to associate with your brand. One possible work around is to use background images instead of the image tag. Background images will not show a broken image icon if they do not load, allowing for more graceful degradation.

The Web-based Email Problem

If you target only the stand-alone email clients, those that pass HTML rendering off to the a web browser or operating system, using CSS in email is pretty much the same as using it in a normal web page. It’s when you start to consider web-based email clients that the challenges of CSS in HTML email become more apparent.

Too Many Bodies

In web-based email, the application has to make some decisions about how to display the email. One problem it faces is what to do with information that is delivered outside of the <body> tag. Since the web-based email client’s interface must send its own set of <html>, <head> and <body> tags to the browser, sending the second set from the HTML email would yield invalid HTML.

Hey, Where’d Everything Go?

Another possible problem for web-based email clients and CSS is that since CSS can affect the entire page, allowing your CSS in the email raises the possibility that your CSS will be affecting their web-based interface. For instance, if you create a CSS rule to absolutely position all <div> elements, you could conceivably render your recipient’s email interface unusable. More likely you will end up just changing some colors and sizes. I’ve seen this happen with Excite’s web-mail.

So my strategy for CSS in HTML email is largely dictated by the needs of these web-based email clients. These clients are drastically diverse, numerous and changing. My approach is based on a lot of trial and error and testing.

The Approach: Inline CSS

Gasp. The horror. Inline CSS? Are you high? How is inline CSS any better than reverting to the <font> tag hacks of yesteryear?

In case you’re new to CSS, CSS can be included via a few methods: via styles in a <style> tag embedded in the HTML; via a linked external file containing CSS information; or CSS can be used in a style="" attribute on any HTML element. The first two options are usually included in the <head> tag and affect the entire page, the style="" method is referred to as “inline CSS” and affects only the element it’s applied to and any elements inside of it, its children.

So why use inline CSS for HTML email? For one, the markup matches the meaning—it’s semantic. You can use a heading tag for your heading and make it look like you want, but it’s still just a heading tag. Any software that encounters it is likely to have an acceptable default way to deal with it, and it will degrade gracefully. The style is permanently affixed to the element it’s styling. And of course there’s no extra tag to keep track of closing. And if you’re not familiar with CSS (and still reading this article) it’s a lot more capable than <font> tags and it’s high time to learn it.

Inline CSS Sticks Around Better

I think the most important reason to use inline CSS is that the inline CSS is usually left alone by email applications. This is not true across the board; sometimes even some inline rules are removed. But generally inline styles are removed a lot less often than styles inside a <style> tag. Web-applications generally pass attributes to “allowed” html elements unprocessed, including the style="" attribute. It makes sense, as there’s no danger of inline styles rendering a web interface unusable.

As an example, Hotmail only renders the contents of the <body> tag of your HTML email, dropping embedded styles included in the <head> element. You can sneak your embedded CSS in if you include it inside the <body> tag (this also works for a few others), but Gmail discards all <style> tags. Both, however, pass inline styles largely unaltered. (The background images are a notable exception; both Hotmail and Gmail do not display background images. As far as I know, there’s no way to get Gmail to display positioned background images. Post a comment if you find otherwise.)

Inline CSS Is Still CSS

A third reason why Inline CSS isn’t going to be as big a pain as you think, inline CSS still cascades via inheritance. With a little creative code layout, you can still use inline CSS in the cascading manner you’re used to and keep it in a format that is easy to read and maintain. The only difference is that instead of creating a rule in an embedded style-sheet, you insert the rules in the style attribute.

One thing to note, use class rather than id attributes. Web-based email applications will sometimes use or change the id of your elements. Sometimes, as in the example below, I use the id’s just to clarify the code, but don’t depend on it for styling.

My Currently Preferred Code Layout

<div id='main'
style='  width:        650px;
background:   #007CC2;
margin:       0 auto;
text-align:   left;
'>
<div id='sidebar'
style='float:       right;
border:      1px solid red;
background:  white;
'>
</div></div>

Mix-n-Match with Embedded Style Sheets

Inline styles work fine for one-off emails that I will code entirely myself. But for email templates, I do want to be able to provide the person who will be creating the final email with access to some heading styles at least. My strategy in these situations is to use inline CSS for all the structural/layout stuff (width, padding, border, background, etc.) and then use a duplicated (once in the <head>, once in the <body>) embedded style-sheet to style the user-created HTML elements (headings, paragraphs, list items, etc.).

This approach insures that when the embedded style-sheet is not available, only the user-created HTML elements degrade to their default presentation, while all my inline structural CSS (that the template user doesn’t need and possibly shouldn’t have access to anyway) remains intact. But be careful not to include inline structural markup in elements the user can delete.

Isolate Your Embedded CSS

I mentioned earlier that the styles in your email can affect the entire page, whether that be the interface of a web-based application or a forward/reply conversation somewhere else in the email. If you are going to use styles embedded in a <style> tag, be careful to be sufficiently granular with your CSS selectors so as not to affect elements outside your email.

I do this by including a class attribute on the first element after the body tag, and I then include that class in all of my selectors. This approach insures that my rules will not be affecting elements outside of the email that I’m creating. The following fictitious example illustrates the problem and solution.

How Not To Change Excite’s Link Color

<style>
.myemail .excite   { background: black;}
.myemail .excite a { color:      yellow; }
</style>
...
<body>
<h2>Welcome to Excite Mail</h2>
...
<a class="excite">Excite Home</a>
...
<div class='myemail'>
...
<a class="excite">Excite email users click here.</a>
</div>
</body>

Word Permeates It’s Ugly HTML Tentacles Via Outlook

Some people associate CSS with the irradication of tables from HTML. Thanks to the incessant innovation from the folks at Microsoft regarding MSWord’s HTML abilities, there’s still a place for tables in the world of HTML email. Outlook provides users with the option of using Word as their email editor. Word has a strange, turn-of-the-century take on HTML and seems to barf on typical <div> layout structure. If this option is enabled, Word will cause any <div> tags forwarded or edited in Outlook to become fairly mangled. Generally this means using <td> tags for layout structure instead of <div>’s as is typical with web-page CSS. Thankfully <td> tags accept CSS just like anything else, and Word seems to find that much more palatable.

Outlook uses an undocumented, non-standard HTML attribute, nosend, when deciding whether to attach copies of the images or keep the external reference when forwarding emails. Including the attribute nosend=”1” will keep Outlook from attaching the image to the email when it’s forwarded, e.g. <img src="http://use.an.absolute/url/to/image.gif" nosend="1" alt="" />.

CSS Shortcuts

Be careful with inline CSS shortcuts. Web-based email client will disregard whole rules, so some aspect of the shortcut rule is not supported, none of it will be applied. For instance, you’ll probably want to use a separate background-color rule when you use a background shortcut rule with an image url. Gmail turns off the entire rule if it includes an image, so your entire background rule will be discarded including the color.

Further Random Tips

• You can generally see what your email will look like in Eudora by using something like Firefox’s Web Developer Plugin to disable CSS. If you’re using tables and CSS, Eudora also ditches the tables so it won’t look exactly the same, but it will still give you a good idea.

• If a link color is critical for legibility don’t rely on embedded style-sheets to change the color; web-based email will frequently override them. Use an inline style="color:red" attribute on the <a> element to set the link color.


• Include target="_blank" in all <a> elements. In most cases it’s redundant, but really there is never a time when you want the link to open in the same window as the email your viewing. Some poorly implemented web-mail clients will open links in the same window.


• Leave the <body> tag alone in emails. The <body> tag affects the entire email, which may be more than your message. Applying a dark background to the <body> tag, for instance, can cause replies to become illegible. And you can’t depend on your <body> tag being there; Hotmail drops it. Instead, place a <div> just inside the <body> tag and apply your styles to that.


• The order in which the content appears in the HTML is important on Blackberries and client’s that don’t use tables. If you’re including a side bar, put it on the right rather than the left.

And of course there are the many other special HTML rendering bugs and tweaks not specific to email that you should to know and watch our for. Hopefully this information gives you a better understanding of the email-specific things to watch out for. If you have questions or need help with an email feel free to post comments. And I’d love to hear about your current best practices too.

¹ There’s a noted gap in my experience with Lotus Notes and AOL email. The research I’ve found shows Lotus Notes having ~10% share of email clients, and I have never had a chance to evaluate its HTML rendering capabilities. The only info I’ve found on Lotus Notes is Tom Granger’s Secrets of HTML Email. If anyone has any insight for me, please don’t hesitate to post a comment.

Update:
Here’s another decent article on the same topic. His approach seems pretty similar.