CSS and Email, Kissing in a Tree

by
Published in Browsers, CSS

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.

Article Continues Below
Article Continues Below

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#section2

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#section3

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:

  1. 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.)
  2. 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.)
  3. I viewed the source code (a feat in itself in webmail clients) to ascertain just how they were bastardizing my precious email.
  4. 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#section4

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:#section5

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:#section6

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:#section7

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:#section8

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:#section9

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:#section10

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:#section11

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:#section12

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#section13

Attributes#section14

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#section15

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.

About the Author

Mark Wyner

A web standards pioneer, Mark Wyner has been designing and developing on the web for over a decade. Mark has accepted awards for visual design, experience design, and web standards interfaces, and stays connected to the web community via his articles and speaking engagements. When he's not obsessing about web accessibility, Mark enjoys his beautiful family of seven, a little bowling, a little golf, and a combination of all of them on their Wii.

100 Reader Comments

  1. Thanks for cutting through the FUD. I’m glad to see that I’m not the only one who’s sick of table-based HTML email.

    On an unrelated note, how do plain-text email clients handle these messages? Or do we still need to send multi-part messages?

  2. Why are you sending HTML email?

    My mail reader is set not to accept externally linked files not to execute JavaScript as both are security risks.

    If you want markup, then please, put a link to the markup in the email, and I’ll go read it if I want.

    You don’t seem to understand a fundamental thing, you have no right to demand ‘return receipt’ via log analysis.

  3. I’m sure this is a very newbie question, but if you’re creating a valid XHTML page (embedding the CSS in the head tag, as per usual…) then isn’t there going to be two head tags in web-based browsers?

    What I’m confused about, then, is that browsers accept more than one head tag. And style tag, for that matter. Both of which, if I recall correctly, are only supposed to appear once in a document.

    So even if you write your XHTML valid, and even if the webmail client is written using valid XHTML, won’t this break either (or both)?

  5. I applaud your efforts to send well designed email, but I think your missing the point here.

    Not everyone uses outlook and even those that do can not wait for the day to disable HTML email and read email as plain ASCII text.

    Sure, you can test to see what works and what doesn’t in various email clients, but if they have styles and markup disabled chances are they will see a pretty ugly and unreadable email with code all over… that means a negative impact on your prospects or readers… is that really what you want to do?

    A simple plain ASCII text email will go miles further than HTML email or even CSS styled email.

    I guess this is what happens when people start to push the boundaries of what a protocol is suppose to do much less the will of the end-user.

  6. Nick and Mr. Harrumphries:

    I think the point here is not whether or not HTML-mail is a good idea, but if you want to do it, how to do so. There is more than one email-newsletter that I subscribe to that is in HTML format. It’s simply more pleasing to read and convenient sometimes.

    I agree that foisting HTML-email upon unsuspecting users is bad. But, if you offer them a choice, at least do it right. I have seen so little on this topic and clients seem to want it so much – for opt-in emails.

  7. Having to put
    td.Feature can be tiresome

    All that you need to do to stop the dots being stripped from the front of class names is put a space in front of them

    so
    .feature
    becomes
    .feature

  8. I believe that your “average” marketing email recipient has no idea that they can change their email settings to plain text.

    In my experience with permission-based email marketing, the third option mentioned was worth the effort (because we had a ton of Hotmail addresses in our opt-in list). We would send multi-part messages–the plain text version always included a link to the HTML version. Though the majority received the HTML…knowingly or unknowingly.

    It would be intersting to get information on exactly what the average person prefers: HTML or text. Though, like I said, I believe if you stopped the average internet user in the grocery store and asked her that question, she would say, “Huh?”.

    Great article, thanks.

  9. Avoid this problem altogether by switching to reno.com email. That’s what I use. The email message can be edited like a word document. Plus HTML will render as source. I myself used Hotmail but was forced to move because they cut off my service. Therefore I became “pianoman@reno.com”.

  10. Good article. I personally don’t like the idea of mail having more than ASCII text with an attachment, but I do understand that about 80% of users out there send HTML-based email, and this offers some good insight.

    I must ask though, with all the problems with AOL, Outlook, etc. Would it be easier to 1) send a PDF that can be controlled perfectly or 2) send a URL for the user to click.

  11. Thanks for kicking off the discussion of standards-compliant e-mail here. It’s an important topic that needs more attention for those of us who care about good design, whether readers come to our sites or we go to their e-mail folders.

    HTML is as important to e-mail as it is to the Web. Remember the basics: “HT” stands for “HyperText.” Can you imagine visiting a Web site and finding all the references to other pages spelled out in URLs in plain text? Colleagues, friends and I exchange interesting links all the time via HTML e-mail.

    I also have helped a few small businesses and groups send HTML e-mail newsletters, and I know from all kinds of feedback that lots of customers and members appreciate them. I’ve spent hours upon hours trying to sort out and outwit the quirks of the major e-mail clients. I can vouch for the wisdom of much the advice in this article.

    I’m still learning a lot of this stuff. But it occurs to me that the key to well-designed e-mail, just as with Web pages, ought to be good structure. Use the right tags for the right purposes, and ultimately your e-mail should come out clean, clear and usable in any client. Then CSS is just the icing on the cake.

    But if someone could tell me how to send an individual e-mail from Outlook XP without it screwing with the code in the HTML stationery I designed, I’d be a happy man.

  12. Nathan: The company for which I work sends multi-part messages, so that’s how I use this technique.

    Andrew: Seeing two BODY tags isn’t the issue itself. Rather, the problem resides in the fact that if you define your BODY tag (body { margin: 0px; }) and your BODY tag no longer exists, your body aesthetics fall apart.

    Bill/Nick: I understand and respect your perspective on this. However, the clients that hire my company demand HTML emails. To convince them to use plain-text instead would be as simple as moving a grazing cow from a dirt road. So at the mercy of my clients’ requests I can build compliant HTML emails with compliant CSS, or I can use FONT tags and Tables. Also, the recipients of our emails have set their preferences on whether we send to them HTML or plain-text formats. It’s not flawless, but it’s fairly accurate. Ultimately, if we have to abide by our clients’ demands, we may as well do it right if we can.

    Everyone else: Thanks for the positive feedback. I’m happy to have helped.

  13. You may want to check out Eudora. When I took a similar quest I found that Eudora is pretty much incompetent when it comes to HTML email.

    Excellent article!

  14. I liked the article as well, but I’ll agree with Bill Humphries: no thanks for HTML emails.

    I personally prefer all my emails in vanilla ASCII and so I’ve configured my all my outgoing emails (including replies to HTML emails) to be plain ascii.

    In the age when more and more people are using Mobile devices to read emails, I think it’s also a good idea to stick to plain text, which creates -smaller- emails (=faster downloads) and is sure to display correctly on any email program. Smaller size and faster downloads also applies for regular desktop machines (hello 56k users).

    As a good example, I received a HTML email the last week, where two of my colleagues had been discussing something for 3-4 emails. The size of the mail was 100k. I replied to the email, quoting it all in -plain text- and the size was 25k!

  15. Chris Williamson wrote: “Colleagues, friends and I exchange interesting links all the time via HTML e-mail.”

    My friends and I exchange interesting links too, but we don’t need HTML to do that.

    What’s more, the first thought that hits me whenever I open a fresh HTML-mail: SPAM!

  16. Let’s get it straight: I hate HTML email like anyone of you, and frankly I don’t see what can be said with HTML email that can’t be said with plain ASCII text. However this is not about us but about our clients – they keep asking us for email campaigns with “punch” and “pizazz” and well, a job is a job, right?

    This article is of particular interest for those of us who after lots of XHTML/CSS web site development, switching to tables and font tags just to please some retarded email clients feels like (and is, actually) a step backwards. And for those of us who have been through the utter frustration of having one of these work on Hotmail. Just as Mark stated above.

  17. Get stupid ANSI. ‘Nuff said.

    HTML emails are evil and the bane of this world, create data wastes, bad markup, clutter mailboxes and generally FUBAR everything up.

    That being said, some people NEED to use HTML email because the boss thinks it’s cool to receive emails that are 500kb and it makes him l33t to spend 5 hours downloading his emails every day. And if you want to keep your job, you listen to the boss. But the fact is you know better than him. That’s why he’s the boss. He’s paid to manage you and not know anything about what you do. Most boses don’t have the first clue about how to send “email campaigns”, they just know they’re “cool” and make money.

    So this is one point I would NOT concede to my boss. Just tell him, listen, HTML emails are bad and they WILL reflect badly on the company as they will clutter the mailboxes of our prospective clients, increase their download times and put us in the same league as spammers, which EVERYONE hates. Company image is so important (unless you’re a spamming company), that usually the boss will understand and say ok. If not, explain again. And again. And again. Until he understands.

  18. Maybe one of the HTML e-mail detractors here will address my first point, which is that hypertext can be just as useful to an e-mail recipient as it can be to someone browsing a Web page. Making the generalization that plain text is the only worthwhile e-mail format is like saying every Web page should display plain text.

    The argument that HTML e-mail itself is evil because spammers use it is like saying HTML Web pages are bad because child pornographers or racists or terrorists use them.

    And the argument that HTML e-mail is all bad because it’s often bulky and poorly coded is like saying HTML Web pages were all bad when everyone was using tables instead of CSS. Someone trying to conserve bandwidth can turn off browser graphics and make perfect sense of a well-structured Web page. It’s exactly the same for a well-structured HTML e-mail message.

    HTML e-mail is more than just a necessary evil. It has as much to offer good, decent people as HTML Web pages do. Instead of throwing out the baby with the bathwater, we should encourage development of e-mail design standards as people have done for the Web. It’s what this site is all about, yes?

  20. Just to respond to a couple point Chris made. Firstly, I agree that the analogy “HTML email is used by spammers hence it’s evil” is indeed flawed. But you made a very good point against yourself too. HTML Web Page WERE bad when they were all tabled. Using tables for layout is BAD, look at it as you want, it’s the wrong use of the tool. It’s like using a butterknife to take the skin off of beef in a slaughterhouse. It’s the WRONG use of the tool and should be avoided at all costs.

    The point is, HTML email is bad for a couple of very simple reasons:

    1) An increasing ammount of people are accessing email through cellphones and PDAs with small screens and low-bandwidth and speed. These devices need the speed and simplicity of plaintext ASCII.

    2) The BASIC function of an email is to convey information from one point to another in a fast and orderly fashion. While it is true that the AMMOUNT of information has changed, it is STILL information going from one point to another. Plaintext ASCII does this just as well as HTML, the only exception is that it doesn’t have formating that is AS nice, but ASCII formating is still fine.

    3) HTML is inherently larger than ASCII. Look at it as you want, HTML IS larger than ASCII. Plaintext is you content, breaks and that’s IT. HTML is you content, breaks, a whole bunch of useful markup and a whole bunch of other useless markup. If the user ends up downloading a total of 40 useless characters, that’s STILL too much. ASCII is slimmer and generally better.

    4) The general audience has NO problems with ASCII emails. The general audience DOES have problems with HTML emails. Why? Viruses. Spammers. Porn. Spam. Virii. Spam. Porn. This is what they recursivly attribute HTML emails to. The fact of the matter is, you are sending this email out to THEM. You want a good impression on them. If only 10% of them know about the problems associated with HTML email, it’s STILL 10%. Nobody has ANY beef with plaintext email. So you’ll be getting 90% happy users instead of 100%. It’s not a good tradeoff if you ask me.

  21. I’d just like to say I’m sorry to Chris is he thinks I’m killing the thread or whatnot. The fact is, these are my views, and that of many other people, and we can’t keep our head in the collective sand for ever. That’s what we ALL did with tables and look how long it’s taken to clean that mess up…

    I actually DID enjoy the article a fair bit. It was well-written, (coming from a family of writters, I know a piece of trash from a well laid-out essay) it displayed a lot of research and a very in-depth knowleadge of the subject discussed. It’s a very nice piece as far as I am concerned and it contains a lot of valuable information.

    Perhaps the most important thing I noticed in the article is how it discussed the particular workings of each email client. I find that rather interesting. For example, it is said that one can override the values in a given web-based-email layout by using CSS. This got me thinking.

    If one where to style the content of an HTML email for a particular web-based email client one could, in theory, totally take over the client. For example, you could set all exterior elements to display: none; and set all elements from the message to position: absolute; and position them where the OLD elements where, thus tricking the user into thinking nothing has happend. You could then tunnel the user’s connection through a given server using YOUR links, thus discovering username, password, and so on. He would never know the difference. You could even call up some malicious scripts or virii.

    Now tell me HTML email doesn’t have the potential to be dangerous if a well-thought-out well-target email is sent out.

  22. thanks for the insight on STYLES with html email. I manage 2 mailing lists that I send out. Normally, I test them on hotmail and netscape, and I also use the old deprecated “font” tags & other non-ww3 styles. It’s like this: ease of execution wins hands-down over over bending ass-backwards to comply with styles that are ransacked by the email client anyways!

    What I WOULD like to know – and what wasn’t mentioned there – is, how to code an HTML email to be readable also by a text-only client. ie, is it possible to “hide” the html and display an alternative text-only email body?

    thanks again for your efforts.

    Rusty

  23. daedlus – I don’t know if this is still the case, but a while back I sent an HTML email to myself at Hotmail. I had visibility:hidden set for links. Sure enough, when I opened the email, all the links throughout the page were invisible.

    Maybe web-based email sites should *only* allow inline styles?

  24. Who uses ASCII email? I do, you do. In fact, we *all* do.

    Least ways, everyone who’s reading this site does. And who reads this site? Developers, developers, developers… 😉

    See where I’m going with this? The people who demand ASCII email are the same people who tinker with their mail clients to switch off HTML email, the same people who futter about with their START menus and screen resolutions, the same people who believe that “most” other people on the web are like them.

    I used to believe that HTML email was the work of Satan himself. However, that was before I started working for a company that sends out permission-based HTML marketing. At first, I shuddered at this. Then I listened to our clients, and then (most importantly) *their* clients – the ones actually receiving the emails.

    Clickthrough rates are through the roof. 95% (on average) of all recipients opt to get HTML versions of the email. Our clients give us immensely great feedback because *their* clients give *them* immensely great feedback on their emails.

    I’m a standards guy. That’s why I’m here 😉

    I’ve recently been chatting with my boss regarding the use of CSS in HTML email. He’s wary, but is coming around. This article is going to appear in his inbox this morning (linked from a plaintext email, I hasten to add!)

    The point is this. We’re all about web standards. One of the mighty Zeldman’s points is that web standards allow one size to fit all. If we are to send HTML email, then using properly styled formatting means that it WILL be accessible to palmtops and cellphones, just as our correctly styled websites will be. Better that than a tonne of tables.

    HTML email may not be ideal for sending those quick messages, but we’re talking about a different message here. You wouldn’t send out hand-written post-it notes in place of company brochures because they weigh less, would you?

    Would you?

    🙂

  25. Even though for some it might seem very pleasing to write emails in ASCII (after all it is all-browser-compatible) you have to understand one rule: people will not go to websites for information [the functional aspect]. In future people will look for experience and entertainment. Therefore, when they will see ASCII email, they will delete it just because it does not give them any feelings/experience/interest. Pictures speak 1000 words! Therefore I welcome with joy CSS/HTML emails.

  26. Using Mozilla Thunderbird as E-Mail-Client has some shortcomings when defining CSS rules. I append my CSS-styles (365 Bytes) via the footer block – but I am not able to append a class to my or define another

    for content as mentioned in your article. 🙁
    Well, at least other T-Bird and Outlook users receive and see my mails like they are supposed to look like.

  27. Allow me to ignore the html=good/evil discussion and throw in 3 issues that have been bothering me so far in my experiences with standards compliant e-mail, and which I haven’t been able to test on a large scale :

    A – A considerable part of my audience is forced to use Lotus Notes as their e-mail client. Lotus Notes ignores my embedded css but serves the rest of my markup as html, including header tags and hr’s, so those users still get fairly readable messages. But Lotus Notes also messes up my anchors and hard coded images. Hence my question: is there a way to get standards compliant html e-mails degrade gracefully in Lotus Notes?

    B – How about e-mail client support for the @media tag to serve appropriate styles to handheld devices? Has anyone been able to test this yet?

    C – Standards complaint html e-mails tend to react poorly to “RE:” and “FW:”, where the users settings take over. Are there any “best practices” to take into account here?

  28. I went though all of this recently. I never even contemplated using tables for html email. As with webpages, you get css or plain text. I was hoping for a real breakdown chart of findings in this article. It was too brief, but a good start on the “next frontier.” (Cough, cough.)

    >>hypertext can be just as useful to an e-mail recipient as it can be to someone browsing a Web page.

    -exactly. I vastly prefer plain text for most emails, but a monthly newletter with thumbnails of the month’s new products is far superior for customers than a plain text link. Customer’s prefer it and sales are better.

    My findings:
    ************

    It was frustrating, as it seems Hotmail was testing email stripping when I was testing them. I swear some would be stripped and some wouldn’t, but I may be flashing back to puberty and hot chicks testing males. Uhh…

    I sent my emails with Worldcast, the crappiest little spam machine going – but free! I started out using a style block. The newsletter is nice and clean looking, much like a css blog. No floats or absolute positioning used. (I tried calling background images inline to check; Yahoo, Hotmail and Outlook 2003 ripped it out.)

    I never noticed any stripping of css rules as noted in the article because I condensed the css block for size savings. Lucky me! Two birds with one stone. I did notice the block was removed from inside my first div (I was trying to hide it in there in a Hotmail test) and placed above, along with html header tags and a doctype, none of which I included.

    >>rules of “cascading” style sheets resulted in mine overruling those of the client
    -The solution offered is off a bit. I, too, used a div around my content to mimic a body tag, but then all you have to do is give it an id (#myStuff) and then use that in your declarations (#myStuff blockquote, etc.) to concentrate the css on your email. Don’t use the id “message” as Yahoo uses that; more below.

    It also follows from above that undeclared properties **can** be picked up from the webmail page’s css. For example, links at Hotmail are a smaller font size with no underline, and they get lost in the text, so each one required explicit styling. Fortunately, I didn’t encounter any problems other than that; just keep in mind what the webmail page’s css might apply.

    >>Maybe web-based email sites should *only* allow inline styles?
    -I say **can** above because here is something really missing from the article: Yahoo is brilliant! It wraps your message in a div with id=message, then it goes through your stylesheet and plunks “#message” in front of every selector to concentrate your css in case you didn’t. Awesome! Congrats to the genius at Yahoo who coded that. Hotmail, get your act together!

    With a css block I just added a short note at the bottom:

    “Note: sadly, Hotmail takes out any styling in emails done through CSS (the modern, shorter way to format HTML). We could redo the entire newsletter using 7,000 fonts tags, but aren’t too keen on that, so if you’re seeing “just the facts” with no pretty colors, that’s why.”

    That note has display:none set in the block, so those with css don’t see it. Nice! Anyway, if your tag structure is good, the email isn’t too bad looking. (In other words, treat Hotmail as the NN4 of webmail.)

    Bonus: I had to try it. With ad-supported newsletter senders you can have an open div at the very bottom with display:none and it will be closed automatically by the receiver’s client and the ad hidden. Worked in the few I tried. Ha!

    >>is it possible to “hide” the html and display an alternative text-only email body?
    -why not just send a multi-part email??? (Of course consider that you just added 50% to your page size, and how many actually use a text only email client anyway.) With css you could have a copy of all the text at the top in one div set to display:none for css clients, then the style block and “real” email below, though some is likely moved above as noted, so a waste of effort really. But this brings up a very good point: using css the html really isn’t very messy at all because no/few attributes are used, so plain text fanatics can easily read it still, analogous to how NN4 users can still use a website without style. Very different from your typical table-and-font apple it might be compared to.

    I then gave up on using a css block:
    ************************************

    Because of Hotmail stripping css blocks, I went to inline css just to try that for a while. Hotmail users are 12% of my list. Coldfusion does much of it for me, so not so difficult, but I might go back to a css block anyway. Adding extra content afterwards with all the required inline styles is a real pain. I only have two fingers, one’s often busy, and a css block saves a lot of time. If, however, you type really well, really give a damn, or work in a really big company where you are paid to waste time, use inline styles if going with css.

    Overall, compared to table-and-font email:
    ******************************************

    Massive plus: CSS email helps avoids spam filters because they look at font tags, red font tags, ALL-CAPS, etc. Not an issue with css. Also the html percentage of the mail is checked – which I’m hoping doesn’t include the style block, but even if it does…

    Nice little plus: CSS email is smaller overall. Also a 17.5kb email I did with inline css was down to 14kb using a css block, so 20% smaller still, and much, much easier to write. Once you’ve done the css once, you can forget it.

    Not nonplussed: CSS lets you more easily copy html from your blog or elsewhere and paste it in. I often do that. Depends how you get/store your newsletter info.

    Yeah, whatever, just send it:
    *****************************

    For all the village “html is evil” people: out of all the css html emails I’ve now sent to a non-web oriented subscriber list of 3000, I’ve never had a single complaint, and subscribers were never even asked if they wanted html, as it is a list developed over years and was always plain text before I switched. (There was a brief interregnum where I tried sending a plain text email with a link to the monthly newsletter onsite, and I might consider that again, but for the user it can be like getting up off the sofa to swim the channel. -“Next month.”) Even if I did lose a few readers – which I highly doubt – it is more than made up for by the increased customer enjoyment/responses gained, as well as the more “professional” patina the html newsletter gives.

    Et voila.

  29. Mark Wyner: “Please note that Eudora?s support for HTML in general is incredibly poor”.

    Lon Baker: “When I took a similar quest I found that Eudora is pretty much incompetent when it comes to HTML email.”

    I wouldn’t say Eudora is that bad. It actually renders HTML emails *using the built-in MSHTML engine used by Windows and Internet Explorer*. So effectively, it should be the king of HTML mail. However, it deliberately strips out code that might be used to breach security. (You can turn this off though.)

    You can also choose to use Eudora’s built-in HTML display routines, but those are poor compared to Microsoft’s.

    I receive a daily email from the BBC with the UK headlines. It comes perfectly formatted, just like a web page, with thumbnails, links, colours and font changes. If that is “incredibly poor” HTML email, I’d love to see the good stuff!

    I feel the criticism of Eudora comes from trying to *write* HTML emails. There simply aren’t many options at all. There I would agree support is poor. But not for viewing incoming mails.

    Eudora seems to use a basic set of HTML tags, but the fun part is that you can edit the source files. For instance, in the program, there’s no way to add an image in your signature. So I opened up the relevant file and added a simple image tag. Viola! It works. So potentially, richer HTML can be created for emails this way.

    Dante Cubed: “I myself used Hotmail but was forced to move because they cut off my service.”

    Why does this not surprise me.

  30. Another way around hotmail email is to use the embedded CSS outside of the body tag, instead of using inline. What I typically do is I place my embedded style tag in the body and also outside of the body so that when hotmail strips the out the body tag I will still have my embedded styles because they were not in the body.

    One Caveat is that it may break the hotmail interface if you use any global selectors like a “a img {}” so use decendent selectors noted in the article.
    It was an insightful article. I am glad someone did all of the testing for me on all of the popular platforms.

  31. Many of this CSS tricks will no work at Lotus Notes Client (6.51) this mail client is more popolar than many of the other tested but most of the web developers usually ignore it

  32. Hello,

    I work in a basement with no windows. We have “green screens” that display words and stuff, bust mostly just words. Next week my boss (her name is Tabitha but we call her “Stabitha” cuz she stabs everyone in the back to get ahead) gets back from vacation and she told me that I had better have a better email system up and running so she can view her HTML newletters at work. I read your article, but it doesn’t talk about green screens. Can I use HTML on our screens with email? If not, I’m in big trouble with Stabitha because me and Francis have just been playing pong all week. She will probably take my Johny Carson bobble head doll and throw it down the fire escape again, which is bad cuz last time it took me two days to find his head in the parking lot and it didn’t go back on so good.

    Thanks for your help.

    Skinny J.

  33. i’ve had lots of success with inline styles and very little success with external style blocks (testing done in Windows: Outlook Express; Mac: Thunderbird, Eudora).

    one helpful trick to eliminate excessive tagging for simple newsletters: set -pre- (preformatted text) as your base style for the newsletter. at this point line returns show up as typed. inside the -pre- you can usually get away with span tags and inline images.

    it’s a pity to have to tinker like this, but the results can be very good. i have to agree with jonathan barrett. mortals/client much prefer attractively formatted epistles to ascii.

    and frankly apart from principle or poor execution or poor design, who can blame them?

    of course, none of this validates especially well – but frankly these emails are ephemera. if they look right across platforms and clients, that’s all one needs at this point.

    but for now keep it inline if you want your clients to see it. and for once, forget about validation.

  34. I’ve learned:
    REVIEW the Spam Assassin test lists for what doesn’t fly.
    NEVER EVER include any javascript in html emails.
    NEVER EVER include flash or even rollover gifs
    ALWAYS set images to a link on your site.

    And if you tag the images with the recipient’s email address, you know they got it (from your log files) and if you tag the links with their addresses, you know the clicked through.

  35. CSS and Email, sitting in a tree. P-A-R-S-I-N-G.
    I’ve noticed a lot of emails I get have links that totally get screwed up, ie that show regular markup but the content of the HREF attribute is a link. Anyone else have this problem?

  36. I work in-house, and I’ve argued with management enough about HTML email (its intrusiveness and lack of interoperability), now I need a quick and dirty way to do this sort of thing. It seems like stuff always get discussed, and its over my head or incomplete. I put an html file on our internal fileserver, and set users account to grab their particular html file as their “signature” (Lotus Notes 6.5) for every outgoing mail. It still isn’t showing up right in some email clients. What’s the best way to deal with the headers in html email? I think that may be the problem. Just trying to put a .jpg file sitting on a web server into an email, without having it attach.

  37. I think you mean “Mail”, Apple’s poorly named email client bundled with Mac OS X 🙂

  38. html email IS good! This is especially true if you’re trying to convince or persuade your audience. Would your attention be draw to a newspaper page that’s full of black text on white paper top to bottom or a full color page with styled text and photos? Unsophisticated users love pretty pictures and colors. Try convincing your client and your boss that ASCII is the bomb!

    Spammers are making it difficult (and they’ve obviously convinced many in this discussion) for legitimate mass mailers to get their HTML messages out. I run an opt-in monthly newsletter, and it’s becoming more difficult each month to reach my subscribers because so many have spam-screeners that block messages until we confirm our identity.

    The big picture: our entire email system is out of date and needs to be reformed to disallow spam and let users confidently receive the information they request.

  39. This is a great article and a topic that I hope draws the attention of those who build email clients. I’m in the business of designing email newsletters and my experience has been that css is great for refinement of an HTML email but not much more. I look forward to a day when a subset of web standards could be applicable for HTML email. Until that day comes, this is my bit to share.

    Where I find css particularly useful is for hiding the ugly but necessary,
    “If you are having difficulty viewing this email properly…” text and link.
    In the P tag where it is contained, I assign it a class from a linked css file with the property {display:none}. If the linked files and css are both viewable, the “If you are having difficulty…” line doesn’t appear. Otherwise it does.

    Regarding the text vs. HTML debate. Unless you are viewing this page in a Lynx browser, I think the merits of HTML are obvious. I would be interested to see if anyone has an example of a linked css, jpeg or gif file virus. I’ve never seen or heard of one which makes me think that administrators who block email with all linked files are being overzealous.

  40. One of the things that really irks me is when a vendor or publisher ignorantly assumes that filling e-mail with HTML code is the “only” way to send their message. PLEASE don’t make the same mistake. A great many of us do not like getting mail as HTML, and flippantly assuming that we are intractable so-and-so’s won’t improve the chances that we’ll subscribe to your site or newsletter. If you *have* to send HTML-ified messages, at least be kind to the plaintexters and use multipart/alternative MIME messages with directions of how to see the HTML version.

    Instead of filling the DATA stream with Web content, why not just send a hyperlink to the actual content, safely hosted at your provider of preference? That way you can stop worrying about CSS or other stylistic “problems,” present your content *your* way, and still make use of data-driven customization–without peppering your message with invasive Web bugs or having to worry whether any given MUA will render your code.

    And finally… to those of you who will still send messages that contain HTML code only, please at least use e-mail blasters that actually understand how to send mail properly. Neglecting to include the MIME-Version or Content-Type tag just leaves your message with all the HTML/CSS code in plaintext, making you look incompetent and alienating your readers.

  41. >>What I typically do is I place my embedded style tag in the body and also outside of the body so that when hotmail strips the out the body tag I will still have my embedded styles because they were not in the body.

    Great trick! I just tried that and it worked fine. Awesome.

    I never included an html/body tag in my messages before, but just added it and an extra style tags before it, and there you go!

    I also tried it without header tags and both style tags get stripped out, so the header tags are a must.

    TIP: the style block before the html needs only to be an empty style tags. Thus no real weight gain.

    So, problem solved? Forget inline styles, I see no reason not to use an external css block now. I think this article needs an update with a summary of these extra findings added.

  42. >> “If you are having difficulty viewing this email properly…” text and link.

    Good tip for that tiny percentage. Thanks, I’m going to start using that.

    >>why not just send a hyperlink to the actual content
    -Not a bad option, as less worries about size, spam filters, readability. I tried that. But many people dial up for their email and disconnect. Or they read it and figure they’ll do it later, then forget. But the above tip ameliorates that issue for html.

    One related tip: place your actual css block at the end of your code before the last div (with an extra empty one before the html tag for Hotmail). Then it’s out of the way if anyone is reading the plain text.

    >>A great many of us do not like getting mail as HTML, and flippantly assuming that we are intractable so-and-so’s won’t improve the chances that we’ll subscribe to your site or newsletter.
    -dual format emails have some problems and are bigger in size. And as noted above, we’re not talking about typical emails, which I, too, much prefer in plain text, but about ones that are obviously better in html, such as newsletters with photos of products, forms, and such. In the real world, I’ve never had a single complaint from my 3000 person list, and they were never asked about format. (A discussion list for webbheads would be different, of course.) For most small outfits, just getting a regular newsletter done and sent is 99% of the battle, so if html is better for the task, use it, and use css for the reasons detailed. -Also, all studies show that plaintexters never buy nothin’ anyway.

    >>very little success with external style blocks (testing done in Windows: Outlook Express; Mac: Thunderbird, Eudora).
    -I had zero problems when testing with Outlook 2003 and Outlook Express 6 on XP. Also, the article says Thunderbird is OK. (Should be, it uses a css editor itself, no?) Were you linking to css, which is definitely a no-no in email, as your results are incongruous?

  43. > Instead of filling the DATA stream with Web content,
    > why not just send a hyperlink to the actual content,
    > safely hosted at your provider of preference?

    Mainly because people just won’t click on that link. But I digress… 🙂

    Interesting thread. Lots to think about. I agree wholeheartedly with the NN4 argument someone came up with. We’ve argued for ages that old web clients needn’t be left behind in terms of content, they just won’t get the whizbang of funky modern formatting. Nice to see that email should be bound for the same treatment.

    Again, I’m not saying that HTML email is what we should be doing. For a message to my mum to say that I’ll be home next weekend, HTML is going to be overkill.

    Someone mentioned viruses/spam etc. Think about it this way – how many “iffy” emails have you had that have been written in well-formatted, well-presented HTML? You know, HTML that looks like it’s had a good couple of hours spent on it – that looks well branded?

    How many was that?

    Okay. Now, how many “I send you this file to have your opinion” plain text emails have you had? Or badly formatted -fests that are selling you blue pills?

    Oh, was that a larger number?

    HTML email should not be used for the quick messages, or where content is *really* heavy (mini-AIR, I’m looking at you!). But for a branded marketing message, plain text is suicide. Especially if you’re wanting to do some sort of clickthrough tracking.

    Click here for our site : http://www.mysender.com/myaccount/?userid=1322324421987&url=http://www.mywebsite.com/#link1

    I don’t think so…

    Web design (and design in general) is all about choosing a medium to suit the message. If I’m sending out an email to subscribers to tell them of an overstock sale of baby accessories, then plaintext isn’t going to make me any friends.

    If I’m sending out a digest of my geek blog, HTML email will get me flamed.

    Choice is the key. Nice to see we can now have choice *and* be able to do it right.

    Thanks to everyone who’s contributed so far, thanks for the research, and thanks to Mark for writing the article. Must have taken some big kahunas, Mark – hope the inbox isn’t burning too much!

  44. Last week I created a css-based newsletter, and my first test results were promising.

    I make the newsletter in Homesite or Dreamweaver, and then copy the preview browser output to an empty Outlook mail. The html, head and body tags are not included that way, but that’s no problem at all.

    I prefer embedded css coding over inclusion of external stylesheets. Only for images I use external linking, but they are very few and not essential for grasping the content, only some logos to create a consistent look and feel. The overall size of the mail is less than 20 kb.

    I have placed the css block in the body part, before the final div. My mail looked good in Outlook and Hotmail, which most of my clients use. Even Eudora displayed the message just as I intended. In some text-only webmail clients I tried there was of course no formatting, but the plain text output was perfectly readable.

    So I don’t see many disadvantages at the moment, and my experience is also that the response of users to stylized mail is way better compared to plain text.

  45. First off, thanks so much for this great article. Interesting observations and thoughtful suggestions.

    I don’t know what the breakdown right now about who wants HTML e-mail, but apparently about a fifth to a sixth of general net users want text only. (I’m recalling this from memory, so I could be wrong on the percentage.)

    E-mail marketers have found that click-throughs from HTML e-mails are much higher than plan text e-mails, so many E-mail marketers want to offer HTML versions. If they can’t send out multipart MIME e-mails, they will likely go with HTML since the text-only group is smaller and the click-through rate is lower.

    Is that fair? Probably not. But I understand where they are coming from.

  46. I’m happy that my article sparked such an excellent debate. It’s nice to see we’re all awake. 🙂

    I’d like to lay a blanket over this battle about whether or not we should be administering HTML emails. And I’d like to clarify how I intended my technique to be used, regarding context and application.

    –/ Context /–
    Sending an HTML email from one’s desktop email client or using it for general email communication is hardly a good idea. This is not what I had in mind when authoring this article.

    My organization deploys emails through a professional administration system to thousands of recipients. This is the correct way to send HTML email, and allows one to monitor its performance. It also enables legitimate companies to comply with the Can-Spam Act (http://www.spamlaws.com/federal/108s877.html) by serving from legitimate domains. In addition, EVERY email we send has a functioning unsubscribe link and an honest subject line.

    Of the emails we distribute, the HTML versions significantly outperform the plain-text. This is because our audience requests HTML, and we deliver what they’ve requested. We don’t send spam; our audience is carefully selected and our lists are diligently sanitized.

    –/ Application /–
    Even though our recipients have requested HTML over plain-text formats, we still carefully test our HTML emails and monitor their technical performance. Moreover, we send Multipart messages which deliver a plain-text version to a user that has requested HTML as their preferred format without fully understanding the capabilities/limitations of their email client. While this method isn’t 100% fool-proof, it significantly helps ensure successful delivery of the right format for the respective user.

    Thanks for all of the wonderful comments thus far. I’m glad I’ve been able to help those of you who send HTML emails out to the world. Compliancy and accessibility doesn’t stop at the browser.

  47. Excellent article, and big thanks for doing all this testing to see how to get around the various email clients’ CSS ignorance.

    However, all this talk about finally being able to use standards-based layout for emails is a bit premature, I think.

    These tips offer insights into how to better get the major email clients to actually read your CSS, which is a far cry from knowing how these email clients actually treat/layout your markup and CSS once you have tricked them into reading it properly.

    We all know how different browsers/platforms differ in their support for CSS, and the same must be even more true for email clients – made to display HTML/CSS as an afterthought probably.

    I’m not saying that you shouldn’t use CSS-only layouts for HTML email, but I would exercise caution, and just as with our CSS-only web sites, test religiously before blasting that email out to several thousand (if not several hundred thousand!) people on an enewsletter list. With a web site, at least you have a chance to correct it before more people visit the site. You don’t have that luxury with an email.

    p.s. This HTML email is bad/good argument is silly. It depends on your audience (and your content)! Remember, it’s about the users, people!

    p.p.s. I’m surprised I haven’t heard anyone insist that we start calling them “XHTML emails.” Ugh.

  49. I beg to differ, Ray. My firm has been sending all of our XHTML emails with inline or embedded CSS for nearly a year now. It’s about time someone addressed the topic on ALA.

  50. Many posts here have complained that Hotmail mangles HTML emails, but it is not Hotmail’s fault that HTML is broken.

    It is not possible to embed one HTML page inside another. Their tags will clash, their CSS will interfere with each other etc.

    Now if email markup came in it’s own namespace…

  51. Just wanted to share one or two points that I have researched over several years of Email Marketing. Just thought I’d pitch in some nuggets…

    1/ Never send Multi-part Mime encoded emails – never embed images into the email, always link externally. If people don’t want or can’t see your images then fine. Images shouldn’t be major functionality (ie. shouldn’t be needed to understand the email)

    2/ Only HTML should be in the email and the content type of the email should by text/html (and definitely not XHTML)

    3/ Never use BODY or other top level page elements.

    4/ Always use .newclass and CLASS=”newclass” in your HTML (remembering the ‘.’ stripper mail client work around), never rely on anything else (80:20 rule)

    5/ The first thing in your HTML should be an HTML comment with a textual version of the email – some people don’t want HTML email, so give them an option. Treat your rendered HTML email as an image, assume the person won’t be able to see it. (hey, I hate HTML email but it’s a necessary evil in some cases)

    6/ When you finally think you are ready to test, make sure you use LYNX (or similar) to check that your page is readable in Text-Only browser.

    7/ Never use non HTML spec tags or tricks that require workarounds depending on the user agent (eg. don’t use the IE specific BGSOUND, or class cascade tricks…) – it isn’t worth it, the email becomes bigger and you don’t really gain anything.

    8/ If you need to embed media (and recommendation is not to ever do this!) then only ever use Flash (OBJECT not Embed) or Java APPLET. If it isn’t either of these, provide a link to a web page with details – this _include_ Windows Media, Real Audio/Video, etc. Either way, never rely on the media working (so don’t tie textual content into the media somehow) and always give details of how to view it in other ways (preferably a URL for an alternative version).

    9/ There is nothing wrong with using Tables for layout (there, that will get everyone up-in-arms, wait for it…) in an HTML email, just remember the point above about using a comment with a textual description.

    K.I.S.S. – Keep It Simple, Stupid! 😉

    http://webziggy.net/

  52. maybe someone could write up a script to convert your source to use inline styles for hotmail.

  53. For HTML emails, I found it best to use your embedded <style> tag within the <body>. It’s not necessarily valid, but more email programs will pick up on it since many ignore the <head> code. Just stick with basic styles for fonts and padding/margins. Do not use any CSS hacks—they will most likely will corrupt all of the styles.

    Also be as specific as possible in your selectors. Like Mark said, do not define any generic tags like A and P since you will mess with email clients. Use class names and IDs that are relatively obscure so you don’t accidentally overwrite something already defined by Hotmail, Yahoo!, and others.

  54. Super article, there really is not a lot of great published, clear, simple info on publishing HTML E-mail. It can be done, although at times it’s a hairy process to say the least!

    Personally it has taken trial and error to get some CSS friendly processes toogether for HTML Newsleters that I’ve worked on.

    A little tip. I’ve found success with most clients including (puke) Hotmail, by doing the following:

    1. Move your styles into the body
    2. Copy and paste and send what is inside the body tags. (No Head, Body, or HTML Tags)

    3. (puke) Hotmail still for some reason doesn’t like to display background images assigned to sytles, so I’ve been making sure that a similar background color is also set. Anybody know a work-around for this?

    4. Finally little testing shortcut. Mac OS X Mail, and Outlook and Outlook Express on the PC, in my experience, render the HTML mail exactly the same as the Safari and I.E. Browser.

  55. Though many proclaim the increase in click-through in HTML e-mail, remember there are also negative consequences, though smaller: send me HTML, and it won’t display in my mailer (mutt); enhance it with CSS, and it won’t look any different, even if I convert it to plain text through lynx or w3m. (Why not use a graphical mailer? I check mail most often over a text-only ssh connection, the best way to keep things consisten when using multiple machines.) In other words, you’ve lost my interest, and your content won’t reach me, just like a Flash-based site (no Flash plugin for PPC Linux, an OS and architecture I often use).

    But, the response goes, I’m among a small fraction of the total number of recipients — HTML (and as suggested, CSS) caters to the majority.

    Accept that argument for a moment. Then, we should only make software for Windows, and ignore Macs. And we should make web sites only for Internet Explorer, and ignore other browsers.

    Isn’t that the sort of ignorance of standards-compliance and accessibility most ALA readers want to avoid?

    So, what’s the standard for e-mail? Plain text, I’d argue — that’s all SMTP servers accept, and what any mailer can display (I’d also suggest that there’s no ‘W3C for mail’ because plain text is so standardized that no central body is needed to maintain it). What’s the standard for web pages? (X)HTML and CSS, clearly — well-written code will degrade gracefully in any browser.

    Why, then, shouldn’t we advocate standards-compliance with e-mail, just as we do with web pages?

  56. If I am not wrong Microsoft Outlook only exists in versions 2000, 2002 (XP) and 2003. You mention Outlook 2001? Thanks for correcting your article accordingly.

  57. I assume you wouldn’t have checked the ‘Receive our mail in HTML format’ box?

    If you are able to serve up different presentation for different audiences why not do it? The idea that you MUST only produce for the lowest common denominator is crazy.

    Even from an accessability point of view it makes no sense – equality of access is not the same as equality of experience.

  58. D.G.,

    I just opened Outlook on my Windows testing machine, and you are indeed correct. And you’re welcome for correcting my article accordingly.

    -> Article currently reads “Outlook 2001/XP (Windows)”
    -> Article should read “Outlook 2000/XP (Windows)”

    My mistake. Sorry, ALA readers.

    P.S. Outlook 2001 does exist, but only for the Mac platform. Therein lies the origin of my misstatement.

  59. Webziggy said:
    “1/ Never send Multi-part Mime encoded emails”

    Why? Wouldn’t this allow non-HTML capable mail clients the ability to display a text message instead of the HTML code?

    Jeff

  60. Of course, there are still those of us who loathe and detest HTML in our emails and go to inordinate lengths to block them.

    This is partly to do with the sheer ineptitude of most people when formatting messages in HTML — enormous or minute headings and garish colours. However some of us also find plain text much friendlier and more efficient, while from a network-pollution viewpoint it is more environmentally friendly, too, without all that extra HTML code garbage to transmit.

  61. Our studio is currently developing a series of email templates for some our clients to work with an email software that allows users to embed messages and images into their everyday correspondence.

    At risk at becoming flamebait in this whole discussion, we’re finding that HTML email *is* a valuable tool if used to add functionality. Right now, we’re embedding photos of the sender, links to directions, chat, downloadable white papers — along with the usual upsell/cross-sell that a typical marketer would ask for. With the email software, a sender doesn’t have the tedium of embedding all of this content by hand.

    For newsletters, HTML email becomes an invaluable way to give users a preview of the content, letting them look before they click.

    A lot of this thread so far reminds me of the vitriol and the dogma surrounding the use of Flash a couple of years ago. Like HTML email, it’s a great tool — if you use it with discretion and keep the user’s needs in mind.

    Mark, I think the best contribution you could make to the community is to post your test results publicly — some of us could really benefit from your experience on a browser-by-browser or client-by-client level.

    Thanks for all the great R&D.

    Claudio

  62. After regularly searching the web for related topics to email and css and coming up with very little, at last an inspired look into this very grey area of development.

    Thank you

  63. you do realise that you’re meant to send emails as multipart?

    a html version and a text version, for those peoples with html formatting switched off, or clients without a html renderer…

  64. Definitely some great things here but I found the article lacking due to the fact that the issues involved are near infinite. I’ve found it impossible to get it across to clients that there are just too many email clients with too many possible settings to get an HTML Newsletter to come out perfect for everyone. Its just baffling and I hate sending out the newsletter because even though I use multipart with a plain text version, every time there are numerous people replying to complain that the newsletter was a garbage of text.

    Anyway, something I just realized. Yahoo E-Mail likes to do keyword replacements for words like body -> xbody and @import -> @ximport. This article explained just not styling to the body tag, but @import can be saved by using @import instead.

    I still can’t figure out why I’m getting reports that Outlook Express in Mac seems to remove all html.

  66. >>but @import can be saved by using

    Don’t import anything. Use a style block as explained in the article. Maybe that’s your problem with OE Mac???

  67. So, what’s the standard for e-mail? Plain text, I’d argue — that’s all SMTP servers accept, and what any mailer can display (I’d also suggest that there’s no ‘W3C for mail’ because plain text is so standardized that no central body is needed to maintain it).

    I think a lot of people here are looking at the HTML which is currently generated by mail clients, and trying to draw conclusions from that. If you take a step back and look at the possibilities, HTML in emails can be used for structure, with nice presentation using CSS as a nice by-product.

    At the moment, with US ASCII text, we have:

    No structure whatsoever (though people often resort to using CAPS and stars for emphasis in heads).
    No metadata
    No support for quote origins, and a broken ‘prepend with >’ standard for indicating quoted text
    Broken support for paragraph breaks, leading to all kind of kludges in clients to strip out and rewrap quotes etc.
    No linking
    Limited support for other character sets (you have to work around this with different encodings)

    Moving to XHTML with CSS for email (while also sending a plain text MIME version to keep support for older clients) *could* give us:

    Structure (note this could be very useful for searching – imagine querying your email for ‘everything with quotes from Jane’ or ‘all heads containing’, or all emails with element xxx (used to flag crashing bugs in a product)).

    This would also give us the flexibility to only look at the data we wanted – have a user style sheet which doesn’t show quotes, which only shows heads, which eliminates images, which only shows intro paras to sections, all these things are trivial with properly formed html.

    Links to other resources on the web, and to other emails (I’d like to see a standard link style for email refs used in quotes for example (aren’t messageIDs supposed to be world-unique?))

    Built in support for different character sets with UTF-8 while remaining compatible with older clients.

    Email is one of the tools we use most – more than word processors for many applications, and yet we accept that the data produced is flat and unstructured, and very difficult to search/manage after the fact. Add to this the control over presentation *FOR THE USER* which CSS/HTML would bring, and email could become far more interesting. HTML email does not have to be about advertising.

  68. Re. http://www.alistapart.com/discuss/cssemail/6/#c7458: “I assume you wouldn’t have checked the ‘Receive our mail in HTML format’ box? …”

    JamesC, I would if I could. More often these days, however, plain text isn’t even provided as an option. I tend to ask about this, and am continually surprised by the number of responses that amount to “we only send HTML” or even “we can’t send plain text.” Even for newsletters, which can have a claim to requiring rich content, I can’t choose to receive a URL instead of 50K or more of HTML.

    So, I accept your point fully that different presentation for different audiences is a reasonable idea; I wouldn’t claim that HTML e-mail is never appropriate or preferable. And, I’m glad to hear your organization gives this option explicitly; my earlier comment likely was inspired by the fact that the organizations that send me mail tend not to be so enlightened.

    The point, then, is that any form of ‘enriched’ e-mail must, as we say for web pages, ‘degrade gracefully’, i.e. the content must be accessible in any mailer. In web browsers this is simpler, since all browsers understand at least a basic subset of HTML, since that’s what browsers do. For e-mail clients, it’s different, since some of them understand any HTML at all — the best solution for which is a plain text option when subscribing. Though you may not have forgotten that, it’s important that others don’t, even in the face of knowing that markup and style can be used well to enrich e-mail. At least the option of receiving only plain text is the sort of least common denominator — the sort of ‘standards compliance’ as I described it — that’s needed.

  69. [mode=’rant’]
    i dont want to read formatted mail, i turn off the feature in my mail client, fair enough…

    …but i still have to download the stuff, and it still sits in my mailbox wasting space.

    any marketing mail that comes through to me with a HTML attachemnet gets binned, period.

    if you want your ‘audiance’ to view nicely formatted pages, include a link – they just might follow it…[/mode]

    sorry

  70. Just for the record:

    The plural of ’email’ is not ’emails’. When the postman arrives, you don’t say, “Look at all these mails I got”.

    And to be ultra-picky, it’s actually e-mail 😛

  71. Okay, for now on you are only able to complain, rant, rave or otherwise SPEAK if, and only if, you first learn correct grammar and spelling.

    That said, I used this technique last week for an HTML e-mail requested by my employer. It worked beautifully. Thank you.

    And correct me if I’m wrong, but if you use an image replacement technique such as FIR or one of its progeny, doesn’t that also solve the problem of people who have HTML off still having to download the images?

  72. I don’t understand why people use HTML for websites. I mean, plain text can include links to, and who really needs all that styling fluff.

    It just creates bigger downloads, and if I want something styled, I make a PDF download and link to it from my plain-text website.

    😛

  73. Whatever you say, Sam I am. I suggest you send an email to Microsoft and Mozilla and such saying to stop making browsers support HTML. I mean, come on. Only 99.99% percent of websites use it.

    The plural of email *is* emails (or “email messages”).
    When you say “look at all the mail I got”, you are referring to “mail” as a collective noun, which is treated as a singular noun.

    But this isn’t about grammar.

  74. Can someone here please fill me in on why you all consider HTML email to be such an evil thing, because I just don’t understand it.

    If the email you are receiving is at your will, you should have been provided an option for plain text or rich text/html in my opinion. If you don’t pick one, either way, you should get plain text.

    Someone was saying that if you want to view something pretty/well formed, provide a link. My email habits must differ quite a bit from yours. Unless the sender is someone I know, I won’t bother clicking on a link in an email. Why you ask? Simple, chances have it that the link is just going to be advertising of some sort (not spam as I might have requested the email, but advertising none the less). So if t hey want me to read it, they would want to provide the crux of the content in the email itself and not just provide a link.

    Al.


  75. Can someone here please fill me in on why you all consider HTML email to be such an evil thing, because I just don’t understand it.

    Because they’re all tech-geeks, living in a pure uncorrupted binary world. The hardcore Linux warriors at my office are just the same.

  76. A reply to daedlus specifically and to those arguing against HTML e-mail:

    You guys are in turn missing a simple point in your counter-arguments: you are making the assumption that those people on the pro HTML email camp are going to be using this technology ALL THE TIME.

    Surely to god you must realise that we’re not stupid. We are more than aware that HTML email is perceived as spam and related crap by Joe Soap user. This is why we’re not sending them HTML mail!!

    The whole point about this article, as with so many articles on this site, is “if you’re gonna use this technology then here is the best way to do it”.

    I have no intention of sending *everybody* in my address book HTML e-mail. However, the vast majority of my clients have SPECIFICALLY requested HTML e-mail for their newsletter and company announcements. They like the topics sidebar I have implemented. They like the fact that my brand identity extends into the messages they receive from me. They are expecting HTML mails because they’ve asked for them, and as a result they do NOT perceive them as spam.

    This is what this whole thing is about. I myself request pretty much all my mail shots and newsletters in ASCII because I find it easier to use, but one or two of them are in HTML because certain features incorporated into the design I find useful.

    And daedlus: to say teh general audience has NO problem with ASCII e-mails is utter rubbish and a sweeping generalisation: pretty much everybody I know has MANY problems with ASCII e-mails. They also have many problems with HTML e-mails. In general they have many problems with e-mail full stop, regardless of format.

    The reason is simple: they’re sick of spam, virii and junk IN GENERAL, and I’m getting more and more ASCII junk than HTML anyway.

    Fundamentally, as with web design, it’s the CONTENT that matters, not how it’s presented. Use the right tool for the job, and if done properly, HTML is just a valid a tool as ASCII for e-mails.

    P.S. Daedlus, I would really like to see how far you get in convincing your example boss that he is wrong in wanting HTML. HE is the boss, HE makes the decisions, YOU just do the work. If said boss and said company send HTML indescriminently, then they probably are already a spamming company, otherwise receipients will (more than likely) already be getting their e-mails in a format they are happy with. If they aren’t only THEN will you be in a position to mention a possible change in e-mail format.

  78. If you don’t want html email, then make it so. But for those of us who are *asked* to make and/or want to make html emails, we should not be berated for trying to do it well.

    Also, I would imagine over time, clients will get better at CSS… i hope…

  79. Hi,

    I understand for IE browsers, there is a little known css feature called expression(). It is a function whereby you can run any javascript inside there. (Someone used this trick to mimick min-width, for example, in IE).

    Is there therefore not the big risk of security flaws of JavaScript executing via ‘malicious’ css, or do most mail clients prevent execution of javascript regardless of how it is invoked?

    — bob

  80. Ok. pro and con arguements aside. I at this moment am trying to create a html email. I’ve created a html file in dreamweaver (and bbedit for that matter) and I’m trying to put it into outlook 2000 to mail. whenever I insert the html file, it strips the style tags out of the head. I’m getting confused between what I’m creating in html and what outlook is doing. help.
    thanks.

  81. Most in the email industry just suggest that you embed your CSS below the html, head, and body tags, since those are stripped n browser-based email.

    Did you find that simply doing that wouldn’t work?

    Interesting about the selector issues. Good stuff—thanks!

  82. To ensure styles look ok in hotmail, just duplicate your

  83. If you have Javascript turned off, expression() doesn’t work. I don’t see how it’s a security risk.
    I found out the hard way that the slightest bit of incorrect syntax with expression can crash IE.

  84. Really the only way to go, especially as it cuts down on the weight of HTML. And many spam filters trigger on that. I do embed the stylesheets as I have found that a linked stylesheet will oftentimes get mangled, eaten or plain not work depending on the network settings of the recipient. And, if the styles dont transmit, it does not matter so much no, because we are all using nice, standards compliant, easily degradable markup, no?

    Another issue is the plain text vs HTML thing. Multipart is definitely the way to go, even if there is a bit of overhead converting the mailing to make sense in plain text.

    Part of me would like to just do plain text, but there is the fact that one must send HTML is it is beginning to replace glossy mailings as marketing materials. Management have enough trouble with not being able to go wild (think tottally flash based emails), much less reducing things to plain text. Not to mention my suspicion that most of the rest of the [non-technical] world likes HTML email rather than stuffy plain text. C’est la vie.

    WWB

  85. Why the appearance of all the purist ‘only send plain-text’ opinions. We do it because it looks nice. The Web can look nice, so why not emails too ?

    A certain amount of formatting can also make things easier to digest.

    It may be worth adding that if you want an overall BG colour, that’s another reason to wrap it all in a DIV, and colour that. Many web-based mail pages ignore BODY BG assignments. I used to receive many a mail that was a plain expanse of white (intended to be white text on colour). Hotmail and Yahoo seem to have sorted this one out. Unfortunately, they’ve also removed the ability to ‘inadvertently’ affect the styling of the rest of the GUI. Perverting Yahoo’s buttons with stolen animated pornography used to be one of life’s simpler pleasures.





  86. Untitled Document

    Dzień Dobry

    Nazywam się Mariusz Zdanowski i pisze w związku z ogłoszeniem które ukazało sie na grupie

    pl.praca.oferowana, Grafik-Webmaster/Warszawa/Stala

    Szanowni państwo spełniam wszystkie Wasze wymagania, posiadam wieloletnie doświadczenie w tworzeniu banerów o wysokim współczynniku CTR, projektowaniu profesionalnych serwisów www.

    Aktulnie szukam większej ilości zleceń lub pracy stałej w Warszawie.

    Zamieszczam linki do ostatnio wykonanych prac, zapraszam do współpracy

    Kontakt

    Mariusz Zdanowski

    mWork@ojej.org



    0601872266

    Przykłady Prac:

    2003-2004


    Fajerwerki, śnieg, muzyka, już szampana każdy łyka, stary rok się w Nowy zmienia, przeto szczęścia śle życzenia.

    http://ojej.org/mmm/x.php?name=imgg/empty.gif&kto=ALISTapart&adr=megapolis.pl@megapolis.pl

  87. My company uses a mailing program that allows our prospects to choose either text or html and if they fail to choose either one we send in multi-part format. The program is http://www.autoresponseplus.com/.

    As for format preference Dr. Ralph Wilson did a survey last year on format preferences. The survey results are published here: http://www.wilsonweb.com/wmt8/email_format_preferences.htm

    Also, I have joined some newsletters that offer no preferences. They usually just say something like only in HTML.

    I personally prefer html mail, but I’ll take text.

    Out of all the mail I receive though I would guess about 90% of it is html.

    These are almost all newsletters, which is one of the only things html mail should probably be used for.

    I like what Marketing Sherpa does with the html version of the newsletters they send.

    At the top of the message they put a line asking if the e-mail program messed up the newsletter and then they link to the article or issue on the website.

  88. Very good and userful article. I would like to add something for Hotmail and CSS that comes out from my own tests. You can use CSS quite successfully with hotmail: you just have to insert your styles INTO the body tag, not before it. That way, Hotmail does not cut them and they work quite good (except for the body which becomes tbody, but with the div tip it’s ok).

  90. Thank you very much for this article.

    I’ve been programming newsletters for the company I work for during the past couple of weeks and I was begining to think that HTML newsletters would ‘require’ tables.

  91. First of all thanks for the pointers on css e-mail, i thought i was gonna have to use font tags & all that stuff..

    Hotmail seems to strip out bacground-images, by changing url(“whateverFile.jpg”) to nourl(“whateverFile.jpg”) which is of course very annoying indeed, as everything else was going so well…

    any ideas for work araound’s (dare i say hacks?)

    persoonally i like a plain text email,
    but well,
    isn’t this new technology jolly exciting?!

  92. This is the same thing that got me in a rage when I attempted to locate a decent webmail interface for a client. They didn’t want to pay for a totally custom peice of webmail software. I couldn’t give them a pre-made solution of what they wanted. So, I bit the bullet and started writing a webmail interface from scratch. 100% fresh.

    So I started a project called TerraMail.

    The idea? Create a webmail engine that would do the honorable thing and mess with the emails themselves as little as possible while obeying ALL RFCs and standards.

    The result? I can now view every HTML based email that I’m sent AS IT WAS INTENDED! The solution? IFRAMEs. The entire system is designed to be as flexible as possible.

    Please forgive me if anone finds it offensive that I’m bantering my own software here, but I feel that letting yall know that there IS a proper solution out there would be highly relevant. 🙂

    We have just finished version 0.2 and are cleaning it up for a proper development preview release. It works for basic email tasks such as reading and making plain text replies. I hope to have a few pages online soon detailing what TerraMail is capable of, our design philosophies, future capabilities, and a demo.

    The curect version supports custom interface templates so you can integrate the system seamlessly into just about any website. It also supports an arbitrary IMAP backend connection for the storage of your emails.

    A couple of the features planned for (and under development right now) TM 0.4 include completed MIME suport for outbound emails. Replies as attachment, replying to ANY part of an email, an address book, and some basic interface options.

    We would also love to hear from everyone about what they want from a webmail interface. What do you like? what do you need? what do you hate? 🙂 Please let me know so that I can make TerraMail be what everyone really wants from an webmail engine!

  93. (Sorry I didn’t reply sooner to this comment on page 6 by Jeff)

    Don’t bother with multi-part:

    *) Some mail clients, especially on *nix text-based systems don’t deal with multi-part.

    *) Why bother – if you put a textual version as a big html comment, then the first thing people will see is the text, not a large quantity of hyper-text markup

    *) Definitely don’t use multi-part in Outlook or similar if they mime encode all of the images into the message – it’ll just make your email bigger, and if there’s one thing _I_ hate… 😉

    Reading the rest of the discussions – it really comes down to – if you want to use HTML then follow many of the tips in this list as many of them help – if you don’t then don’t. You need to think about your target audience – which mail clients are they likely to use… are they technically savvy enough to switch off Javascript, etc.

    Oh, and don’t forget that when SP2 for Windows XP comes out the default image download setting for Outlook Express will be to not download images (as recent Outlook 2003).

  94. I’m coming to web design after years in print design, where you can rely on ‘what you see is what you get.” So trying to do the email newsletter I am working on is quite frustrating, and trying to find info on whether you can use CSS with it has been next to impossible.

    I use Adobe GoLive, and people on the forum there just say “don’t use CSS for email.” Nevertheless, I checked a lot of the email newsletters I get and they all seem to reference CSS.

    Not being a developer, I’m not sure I can implement the advice in this article, but I appreciate it anyway.

    The heated debate about plain text vs. HTML email is also very interesting, partly because as a non-techie I didn’t even know it existed. I like HTML emails for newsletter-type stuff because they look more like something printed on paper, and are easier to read. A long plain text email (like I receive from Graphics.com) is too much work to read because you can’t quickly scan to see if you are interested in anything. Good design/layout is not just pretty — it is useful to the reader, no matter what medium it’s in.

    I think the average Joe is used to seeing sophisticated web sites, and is coming to expect sophisticated-looking email from businesses. A professional look is important because it says something about the sender and their product or service. I bet the average non-techie user isn’t thinking about the “behind-the-scenes” types of things the experts here know and think about.

    Future email users like my kids are growing up taking all of this stuff totally for granted. They’re IMing lots of people at once, surfing and gaming online, and generally being raised on a high level of graphical communication. They can’t write an email without loading it with animated cartoons from smiley central. My pre-teen kids don’t have them, but how many teens are carrying around cel phones with cameras in them? Does anybody really think this crowd is going to demand plain text email?

    Thanks to everyone for some very interesting reading!

  95. Great article and thread[s]. Thanks for the encouraging facts and strategies.

    We’re redesigning our promotional email campaign — sent out to over 600m subscribers weekly.

    As we’re working to integrate CSS into our HTML offering, our preliminary delivery tests look great for all domains but two: BellSouth and EarthLink. The results aren’t about whether the styles were stripped out or not, but that the email itself never got through the ISP to any recipients.

    In each case, our historic delivery rate runs at 100%; with the CSS test, delivery dropped to 0% for these two ISPs; all other ISPs retained full delivery rates. The test email contained CSS styles embedded within the body.

    Curious to see if anyone has either experienced similar results, or can offer a clue/hypothesis regarding the cause of this anomaly.

  96. Hi,

    Anyone familiar with reading html mail in Yahoo webmail? Seems that alle the urls’s to images are replaced by a yahoo url..

    Thanx

  97. I can’t believe you went thru all this. It must have taken you ages. I’d rather send a plain text message, with maybe a URL.

  98. does anyone here know how to send html formatted emails from osx/macintosh?!? This should be possible?

    WEZ

  99. I’ve read with interest the comments from people who complain about HTML e-mail. In all the vitrol it occurs to me that most are missing the fundamental point: user choice.

    If I go to a site that gives me a choice between plain text and HTML e-mail then I get to decide as the subscriber. Folks that happily choose to have HTML e-mail sent to them should not be subject to the whims of e-mail client programmers. That would be like having a government representative read the newspaper to you, censoring as he went along.

    If I want HTML e-mail I should get it displayed, as much as possible, the way the designer intended.

    Now, if we can just get AOL to even *think* about standards, e-mail, web, or otherwise, I’ll be a happy geek.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA