views:

144

answers:

6

What are the proper practices in designing an email with a reasonable expectation that it will show up correctly for Outlook 2003, 2007 and in a webmail client? I'm subscribed to various email newletters and have viewed the source on them and have seen some of them have 2000 lines of HTML&CSS along with IF statements I've never seen before (I assume related to determining versions of outlook).

Is there a tool either free or commercial that can be used to create the markup? Is there a standard pattern on how to apply these huge stylesheets I've seen?

+3  A: 

Designing for email is a nightmare, due to Microsoft's adoption of the Word HTML engine for newer versions of Outlook. There's no tool that I know of, but this guide will give you a helping hand when trying to decipher what client supports which CSS:

Guide to CSS support in email clients

Mark B
Looking at that list, that is a nightmare for seeing how many X's show up.
Chris Marisic
Yep, it's very, very frustrating, especially when standards and compatibility in web browsers has come so far in the last few years. You wouldn't believe how much swearing HTML email design wrings out of me...
Mark B
A: 
  • Keep the width fairly narrow (~600px at a guess).
  • Use tables rather than CSS divs.
  • Make sure it works in IE6!
DisgruntledGoat
That was my starting point and even that isn't reliable, even a simple single column table with a fixed width gets messed up where the table cells expand for no reason past the width.
Chris Marisic
A: 

HTML cannot be successfully implemented in email for three reasons.

1) HTML is designed to work for the HTTP protocol (web) only and not SMTP protocol (email). This is clear in that the head of an HTML document supplies data relevant to the processing of the document in accordance with a transfer over HTTP. Since HTML supplies no conformity to the conditions supplied by the SMTP protocol it is on its face in compatible. As of this time there is no standard of any kind for describing the format of content in email.

2) HTML is not a presentation language. HTML is intended to supply structured meta-data to content and is never intended for presentation. HTML is only used in email for presentation, and as such is often abused and used in complete violation of the standards.

3) A single document in email can have multiple authors each with independent header information. Such a document is called an email thread. HTML has no such convention. When HTML is supplied in email it may look fine to the initial user who receives it, but when replied or forwarded it will look like crap and fail to do its job, which is likely not doing anyways. To my knowledge Mail Markup Language is the only markup language containing features to address and serve multiple author contributions to a single markup language document without conflict as is necessary to support an email thread accurately.

Those three reasons are why HTML is completely incompatible with email and is not capable of being successful.

A: 

Take a look at this great guide over at Campaign Monitor.

roosteronacid
+1  A: 

It's extremely difficult to make emails that work across all the clients because they use different rendering engines from web browsers, where the design was likely developled. Try using LitmusApp's email testing service, which will give you screenshots in how your email will appear in different email clients.

Browsera
A: 

Oy. Such awful answers.

See? This is what happens when everyone decides that using tables instead of css is some kind of taboo. Everyone's limiting themselves with such CSS arrogance and elitism. When all one has is a hammer, everything looks like a nail. Unbelievable.

One poster wrote: "That was my starting point and even that isn't reliable, even a simple single column table with a fixed width gets messed up where the table cells expand for no reason past the width."

Fixed width is what got you in trouble. A 600-pixel fixed-width table is obviously going to be wider than a 400-pixel email viewing window/area. It doesn't expand wider, it IS wider. [sheesh]

There is no way to predict how wide will be the recipient's email viewing window/area. So, create a single table, but set it's width to 100%, not a certain number of pixels. And set its height to "auto." Make its padding nice and wide... 7 to 10 pixels, minimum.

Then just do everything within that table as you normally would, but stick with vanilla HTML4, avoiding XHTML, DHTML, XML, java, javascript, etc., etc. Just HTML4. No CSS, either. Just HTML4. Period.

Use images that are on a web server somewhere that can be linked to using normal http:// URLs, and then just link to them using normal img tags, placing the entire URL of the image (including the http:// part) between the quotes, as in...

src="http://www.website_url.com/filename.jpg" (or .gif or whatever)

...and avoid using the "alt" feature or anything fancy.

If you want to strictly control font size, then don't hesitate to use the "span" tag since it will work in nearly every email client... just dont get too fancy with it.

Also don't make your images too big... especially, don't make whatever is the "header" or top image too wide. Setting the table width to auto won't help much if the graphic remains 600 pixels wide and the receipient's email viewer is 400 pixels wide. Use a graphic that will nest nicely in the upper-leftmost corner of the email message; and use fairly small photos and other graphics.

Do all that and you should find that the email will look the same in pretty much every email client. Double-check by using...

http://litmusapp.com/email-previews

...as another poster, here, suggested.

Hope that helps.

Gregg L. DesElms Napa, California USA gregg at greggdeselms dot com

Gregg DesElms
So basically you're response is to design a fully fluid but table based email design template, without really using css? I am rather skeptical to say the least when it was myself that stated a single column with a fixed width would EXPAND past it's width, and nothing relevant to viewport as the table was WIDER than it's entire width.
Chris Marisic