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 tag. Since the web-based email client’s interface must send its own set of , and 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