Using style sheets in HTML email newsletters
Posted by David Greiner on February 11, 2005
Most people who've attempted to recreate a sophisticated design in HTML email have run into a wall when using CSS, either in the form of inexplicable mangling by email clients or a pronouncement by an email administrator stating that CSS is "against the rules". If you're not content to roll over and use font tags in your HTML emails, read on.
Despite prevailing wisdom to the contrary, you can safely deploy HTML emails styled with good old-fashioned CSS. Yes, we really just said that. Not all attributes will be invited to the party, but many of them work flawlessly with this method.
Most people who've attempted to recreate a sophisticated design in HTML email have run into a wall when using CSS, either in the form of inexplicable mangling by email clients or a pronouncement by an email administrator stating that CSS is 'against the rules.' If you're not content to roll over and use font tags in your HTML emails, read on.
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 of 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).
Permission to use this article was given from the author Mark Wyner, which originally appeared on A List Apart.
14 comments so far
Stay in the loop
Prefer updates via email? Sign up below and we'll send you all the good bits each month.
Dig into a category
- Articles/Tips
- Designer Interviews
- Email Newsletter Design
- Happy Customers/Press
- New Features & Updates
- Observations & Answers
Stephen Jones
wrote on March 26, 2005 05:34 AM
I found this very informative since I have been running into problems creating html emails that don't display correctly in various email clients.
Jon Roobottom
wrote on March 31, 2005 12:09 AM
Brilliant! Just what I was looking for.
Matt Miquelon
wrote on April 6, 2005 07:36 AM
I have been looking for newer content on this subject since although this was posted recently, the original article is over a year old. It's still a great article and perhaps is the definitive authority if there is nothing newer available. i am going to try it and see what happens.
Chris Vivion
wrote on April 28, 2005 12:33 AM
The most steadfast way to get around all of this, though it requires a little more code, is to simply follow the hotmail way and include all styles inline.
Abacioaei Diana
wrote on May 6, 2005 06:21 AM
Very very helpfull.Thank you.Regdards.
Ross
wrote on June 6, 2005 10:39 AM
this is good stuff, i got that problem too, previously had to put in two dots to avoid dot stripping , bad practice.
this blog really helps lots, thanx man
Dave Greiner
wrote on June 6, 2005 08:59 PM
Hey Ross, glad to hear you find the blog useful.
You'll be pleased to know that we have a very exciting follow up to this article coming soon that everyone should find really handy. Stay tuned...
Rene
wrote on July 7, 2005 03:09 AM
You've definitely uncovered alot of the major problems with styles in newsletters. I've been using a combination of styles and font tags for a long time now - there are just so many email clients out there that it is impossible to test them all and having font tags as a backup seemed to be a good alternative. This article makes me believe it is now possible to ditch the font tags.
I think many designers have figured out their own workarounds to problems that are very similar to yours. eg/ For the Hotmail style-stripping, my workaround involves adding the styles after the body tag and thus they are not stripped. For the periods getting stripped, you don't necessarily have to add the class selectors - just make sure the period doesn't start the line of code - put it after the closing bracket } of a previous style. eg:
} .pagetitle {color : #333333; font-size:18px; text-transform: uppercase;
} .sectiontitle {color : #FF984B; font-size:14px; font-family : times new roman;
}
Feel free to contact me through my website if you want examples.
Kumar
wrote on November 23, 2005 09:55 PM
The RADIO box name attributes are removed in hotmail when we send any Html form campaign to hotmail account.
HTML code inside the form tag:
From Hotmail Inbox:
Kindly help me to overcome this issue.
Thanks in advance.
Dave Greiner
wrote on November 23, 2005 11:08 PM
Kumar, unfortunately HTML forms just don't work in Hotmail. Check out this article of ours which explains why.
ByteDreams
wrote on February 5, 2006 02:17 AM
very helpful article(s). I don't create newsletters per se, but rather was looking for ways to dress up my personal emails, at the same time getting practice with html and css. So, I'm actually looking for ways of creating stationary - that works, LOL. Thank you for the great info. I too wonder about Thunderbird as I think was mentioned in one of the other comments. One reason I avoided using it because it didnt seem to have a feature for stationary, and like personalizing my emails.
silverhay
wrote on February 18, 2006 12:02 AM
i am searching for a solution to use stylesheets in html newsletters on the horde framework.
I haven`t found one yet.
Greetings
joe smith
wrote on April 26, 2006 12:13 AM
What about Gmail? Kinda missed the fasting growing webclient out there!
Dave Greiner
wrote on April 26, 2006 07:51 AM
Joe, Gmail is covered in Mark's follow-up article on the same topic.
Got anything to add?