More about HTML Email Template

Today I came across these 2 great articles regarding HTML email templates, and they are must to read resources if you are new to HTML email template writing. Last year I did some email template composing, and lots of gotchas and questions are addressed in these two links.

http://hub.tutsplus.com/tutorials/what-you-should-know-about-html-email--webdesign-12908
http://webdesign.tutsplus.com/tutorials/htmlcss-tutorials/build-an-html-email-template-from-scratch

Here are key points I copied and pasted here for future reference :
Part 1: General introduction
If you are already familiar with web development, forget everything you know about it.

The worst thing you can do is get angry that you can’t use DIVs or that margin isn’t fully supported. So forget everything you know about semantic HTML and the latest CSS spec.

The best way to test is using Litmus or Email on Acid. I recommend taking out an unlimited plan with either of these companies because being able to test frequently is really important.

The two services that I use the most are MailChimp and Campaign Monitor.

Image-reliant emails with no text are more likely to be marked as SPAM and so are emails with really long image filenames.

Run a SPAM test through your testing account with Litmus or Email on Acid before you send your email, to make sure all your hard work isn’t headed straight for the Junk folder.

Frameworks like the HTML Email Boilerplate are full of wonderful tricks and snippets that you can implement piece by piece. However, if you are just starting out I don’t recommend using it as a starting point as it contains a lot of elements that you won’t need. Boilerplates can often make it more difficult to troubleshoot any issues if there is a lot of unused code in your file.

Using an XHTML doctype generally has the fewest quirks and inconsistencies between documents. I use XHTML 1.0 Transitional because it has proven itself to be the most reliable doctype in my experience.

The viewport meta tag is telling the device to set the viewable area to the width of the device’s screen. It also sets the initial scale to ‘normal’ which is neither zoomed in nor out.

Email is All About Nesting Tables, you need to use lots and lots of nested tables because neither the colspan nor rowspan attributes are properly supported.

Again, because of the lack of standards support, it’s not a great idea to use standard tags like h1, h2, h3 or p.  Your best bet is to place every block of text into its own cell and apply inline styling to that cell

You can’t apply multiple classes to things in HTML email because it is not supported. Every element can have a maximum of one class.

You can’t use shorthand for things like font size (i.e. style="font: 8px/14px Arial, sans-serif;") because it is not supported.

It’s good to give your images names that are short and meaningful because it will improve your spam score.

It’s also a really great idea to try to keep your entire email as small as humanly possible: under 100kb is ideal but not always possible, under 250kb is pretty standard.

For your main container elements always set the size in pixels. You can then use percentages inside your containing element if you wish.

Responsive Email templates
http://zurb.com/article/1119/create-emails-for-any-device-introducing-

Part 2: Build Template from Scratch
If an attribute exists in HTML, use that instead of CSS

Always remember to use the full six characters of a hex code, as three character shorthand won’t always work.

When using padding in email, you must always specify every single value (top, right, bottom and left) otherwise you can get unpredictable results. Note that it’s safe to use padding on TD tags but not on P tags or DIVs.

We’ll insert our image, adding alt text and adding style="display:block;" which is a common fix that stops some email clients adding gaps underneath your images.

If the contents of your header are really important to your message, don’t use an image-only header. Remember, images are blocked by default for most clients, so if there is an aspect of your email that is crucial, never include it as an image.

If you always have pixel widths on everything, you can end up with a lot of values to override with media queries. If your nested table widths are based on percentages, then when you adjust the width of the parent element, everything will adapt accordingly.

Because we want a ‘margin’ in between these two cells, but margin isn’t supported, we’ll create a three-column table with an empty cell between the two outer columns.

Be sure to zero your font-size and line-height and add a a non-breaking space character   in the margin cell.

We’ll also set the valign to "top" for both cells so that they will vertically align to the top, even if one column has more text than the other. The default vertical alignment is "middle".

As we need multiple rows, we’ll nest yet another table because we can’t use any colspan or rowspan tags.

Let’s run this through the W3C Validator to make sure nothing is bad or broken.

Next we’re going to run a test through Litmus to make sure the structure of our email works great.

Time to turn off the borders and see it looking beautiful. Go through and replace every occurrence of border="1" with border="0".

As a final touch, I’m going to add 30px of padding to the bottom of the very first cell, to prevent our email from stopping abruptly at the bottom in some webmail clients (like Apple Mail), and 10px of padding at the top, so that our blue header has a little bit of breathing room.

If you have used any comments, get rid of them. Some email clients can choke on comments so it’s wisest not to have any unnecessary code anywhere in your files.