Best Practice: Help with HTML | Predictive Response

Best Practice: Help with HTML

Design for the lowest common denominator first

Every single email client reading your email is going to have its own rules about how it deals with HTML emails, so you are going to have to design for the lowest common denominator. Think it’s a pain having to test websites in 4-5 different browsers? It’s much worse with email. Here is a partial list: AOL (multiple versions), Comcast, Earthlink, Gmail, Hotmail, Lotus Notes, Mail.com, Outlook (multiple versions), Thunderbird, Windows Live, Yahoo!, Mail.app. Not to mention mobile clients.

Our Insight test does this for you. If you run an Insight test for your email edition, you will see an email preview of your content on over 30 email clients – and also receive a spam analysis of your email content as part of the test.

info1 Reference: For more information on our Insight tool, click here. If you do not have access to an Insight test, please complete a support ticket.

Assuming you have a fairly large list you are sending out to and have no idea what kinds of email clients they are using, you will need to think in terms of what you can’t do more than what you can do.

What you CAN’T do:

check Include a <head> section with styles: AppleMail.app supports it, but Gmail and Hotmail do not, so it’s a no-no. Hotmail will support a style section in the body but Gmail still doesn’t.
check Link to an external stylesheet: Not many email clients support this, best to just forget it.
check Background-image / Background-position: Gmail is also the culprit on this one.
check Clear your floats: Gmail again.
check Margin: Hotmail ignores margins. Basically any CSS positioning at all doesn’t work.
check Font-anything: Chances are Eudora will ignore anything you try to declare with fonts.

There are quite a few more things you should be aware of. For a great list of what online email services support, check out this article.

What you CAN do:

In two words, inline styles. It’s not as awful as you might think, since we are basically developing a one-off email, inline styles are not nearly as egregious as using them on a website. Need a big green title for a block of text?

<h3 style="color: #1c70db;">NOW $159</h3>

  • The big can-do is images. Think creatively on what you can do with images.
  • Since you will be using tables, think gridular. Grids are designers friends, there is lots you can do with a grid.

Tables are still the standard.

Take a look at the code of almost any HTML email you’ve gotten. It is most likely formatted with a table. Tables are still the best way to achieve consistent results across email clients. The email equivalent of the browser window is the “viewport”, or the area in an email client dedicated to showing the actual email. This varies quite a bit. A very common technique is to set a table with a 100% width with a nested table inside of it that is centered with a static width. This seems to work very well. The outer table is also your big chance to set the background-color for the whole email. Too bad we can’t just use a div with auto left and right margins for centering, but it won’t work most email clients.

Help!

If you just don’t want to think about all these nasty inline styles screwing up your code and all the little rules of what will work and won’t work, don’t worry! There is a really nice (and free) preflight service out there called Premailer. With Premailer, you just design your email as a webpage (still think tables), then submit your URL. Premailer will parse the HTML and convert all your styles into inline styles for you, as well as give you a list of CSS warnings on things you are doing that might be dangerous and for which email clients they are dangerous. Handy!

Quick tips!

  • Remember to use full paths to images, not relative paths. (e.g. http://www.yourserver.com/email/images/logo.gif). Also, link to images from your own server, not anyone elses.
  • Check with your ISP before you go out sending thousands and thousands of emails, they might think you are a spammer.
  • Test, test, and test again with as many different email clients as you can possibly get access to. You will definetly want to test the major online clients like Gmail, Yahoo, and Hotmail, but also definitely check Outlook, Mail.app, and as many other desktop clients as possible.
  • Don’t go over 600px in width. Even that is pushing it. If your design can handle it, 440px is closer to ideal.
  • Think of any extra CSS you may use as upward-compatibility. You can always include some header style CSS if you want, but think of it as a bonus for people using email clients that support it. Then turn it off completely and make sure the design still makes sense.
  • Try not to look like SPAM. Pretty obvious, but just writing good code and honest copy should keep you out of the can here.
  • Just like in web design, it doesn’t hurt to think above the fold. Meaning what users will see before they have to scroll.
  • Use your footer like a footer. This is a great place for lots of things including phone numbers and addresses, about information, unsubscribe options, and perhaps a little reminder of what this email is and why the reader is on the list.
  • OBEY THE LAW. The CAN-SPAM act became law on Jan. 1, 2004. It says there many things you must do as a commercial email-er. Highlights are basically don’t be deceptive, and that you MUST include a physical mailing address as well as a working unsubscribe link.
excerpted from http://css-tricks.com/using-css-in-html-emails-the-real-story/
(0)(0)