CSS and Email, Kissing in a Tree
Originally published on the A List Apart website.
Despite prevailing wisdom to the contrary, you can safely deploy HTML emails styled with good old-fashioned CSS. Yes, I really just said that. Not all attributes will be invited to the party, but many of them work flawlessly with this method.
First comes love: unconditional acceptance
From web design publications, shop-talk conversations, and declarations from email administrators, I learned that certain email clients slaughter CSS by stripping out the styles or truncating the headers. I learned that if I ever dared to use CSS in an HTML email, I should link to the style sheet rather than embedding it.
I never read anything to the contrary or encountered an email administrator who allowed my use of CSS without an all-out war, so I accepted the conventional wisdom. But when I got fired up about the whole thing and decided to experiment, I was amazed at what I uncovered.
Then comes marriage: questioning conventional wisdom
I decided that the only way to find a method for using CSS in HTML emails was to question all that I had learned and to break all the “rules.” Having been freed from those rules, I explored every technique that showed even the slightest promise. Here’s how it went down:
- I designed an email using a linked style sheet and blasted it through a server-administration tool to multiple addresses connected to multiple web- and desktop-based email clients. (While I didn’t conduct the test using every email client, I did test the market leaders on Mac, PC, and Unix.)
- After a couple of rounds, I moved forward with embedded styles. This turned out to be my first step to success. (In further support of embedded styles, it is important to note that AOL versions 6.0+ will reject any email linking to external style sheets. Yes: reject, bounce, slam the door in your virtual face.)
- I viewed the source code (a feat in itself in webmail clients) to ascertain just how they were bastardizing my precious email.
- Finally, I used my assessment of the mangled code to test methods that would, in theory, prevent such mangling from occurring.
When I viewed the source code, I discovered there was even more going on than I’d suspected. It was unbelievable. In fact, much of the HTML wasn’t even HTML — it was mixed-breed coding and (presumably) proprietary tags.
Then comes the baby in the baby carriage: results and recommendations
Every email client had a different way of rendering the code, each with its own unique bugs, quirks, and methods for handling CSS. What follows is a list of the most significant challenges along with their solutions.
PROBLEM:
The shells of web-based clients are built using HTML, which consequently results in the appearance of two body tags when displaying an HTML email message. Some clients attempt to resolve the issue by stripping the body tag altogether; others append the tag with an “x,” thereby changing <body> to <xbody>. In both cases, the style defining the body tag becomes null and void.
SOLUTION:
Envelop the entire contents of your email in a div and apply your intended body attributes to the div instead. Voila! A simple and compliant remedy, using only one extraneous <div> tag.
PROBLEM:
Some clients rendered my email with no style whatsoever. I first attributed this to the stripping of styles, but I then discovered that the styles were clearly visible in the source code. I subsequently spent a good deal of time attempting to uncover the culprit, testing countless versions of the email. Alas, the problem was right under my nose: the styles weren’t being stripped — the dots (.) preceding their names were. Therefore, .Feature {} became Feature {}, resulting in a meaningless style definition.
SOLUTION:
I used class selectors, which ensured that each style would begin with a letter instead of a dot. So .Feature {} would become td.Feature {} or div.Feature {} (depending on the application). A somewhat mundane fix, but effective and (again) compliant.
PROBLEM:
Because webmail clients are using their own style sheets, and because they preceded mine, the cascading rules of “cascading” style sheets resulted in mine overruling those of the client. So my pseudo-classes and element definitions (such as a:link {} and td {}) inadvertently altered the design of the webmail client itself. D’oh!
SOLUTION:
I customized every definition. Thus, a:link {} would become both span.Feature a:link {} and td.Content a:link {} to accommodate HTML links in both locations in the document tree. This unorthodox approach adds a good deal code, but ensures that my styles are applied only to the elements in my email. It also affords respect to both the designers of the webmail client and those using it. And, most important, the resulting code was compliant and functioned as intended.
PROBLEM:
Hotmail: the biggest demon of them all. It has no mercy for HTML emails utilizing CSS. It not only eradicated my styles, but also all of the following tags from my email: <head>, <title>, <meta>, and <body>. Kiss aesthetic design goodbye.
SOLUTION:
I recommend carefully considering how far you want to go to accommodate Hotmail’s ineptitude, because the following method adds the <strong> tag to “dedication” and “diligence.” Since the <body> tag and everything preceding it are gone, the only remaining method for applying CSS is Inline. Inline styles are inefficient and tedious, and I’m sure you’d “rather be golfing,” but it works. If you expect heavy Hotmail use by your intended audience, you can use this method to help ensure success. But if Hotmail is not an issue for you, you can skip this step and instead take care of the important things in your life, like eating and sleeping.
Notes
ATTRIBUTES Before you rake me over the coals because you’ve found an attribute that fails using any of these techniques, please be aware that I haven’t yet tested all CSS attributes for success. I did test common attributes and those that I use frequently. You may find that your favorite attribute fails, and for that you have my sympathy and my encouragement to test additional methods.
CLIENTS TESTED I tested MailApp 1.3.2 (Mac), Squirrel Mail (Mac/Windows), AOL 7.0, 8.0, 9.0 (Mac/Windows), Mozilla Thunderbird 0.5 (Mac/Unix), Yahoo Mail (Mac/Windows), Hotmail (Mac/Windows), and Microsoft Outlook 2001/XP (Windows).
I would love to hear from you if this technique fails in your environment. Please note that Eudora’s support for HTML in general is incredibly poor, so I excluded it from testing altogether.
#CSS #HTML #Email #Development #Code #AListApart #WebStandards #EmailStandards
Like this? Find out when I publish new work.
