What is a Blacklist?

A Blacklist is a database of known internet addresses (or IP’s) used by persons or companies sending spam. Various ISP’s and bandwidth providers subscribe to these blacklist databases in order to filter out spam sent across their network or to their subscribers.

There are several Internet organizations (i.e: MAPS) who maintain lists of IP addresses that are known in some way to support spammers (having open relays, hosting Web sites, distributing marketing spamming software, etc.). If you operate a mail server, usually there is something in its configuration (e.g., Sendmail’s rulesets) which can consult these lists, called “blacklists” or “blocklists,” in an automated way when receiving a piece of mail. Usually this takes the form of a DNS lookup of a specially crafted name.

For example, if MAPS discovers there’s an open relay at address 10.20.30.40, they will put an entry for 40.30.20.10.relays.mail-abuse.org in their DNS servers. When your mail server is receiving mail, it looks up the sending mail servers IP, which in this example is 10.20.30.40. Then it does a nameserver (DNS) query for the above string.  If your mail server gets an expected response, it throws an error back to the email client, and refuses to accept the email. If instead it gets back an error (due to no record being there for example), it assumes the email is coming from an OK source and proceeds.

Our blacklist lookup simply allows you to make sure your sender IP is not currently blacklisted.  If you use an email service provider (ESP) for this process, be aware that many ESP’s have multiple IP addresses for which they send mail through.  Of course they do this for load balancing purposes but also to protect and ensure that one of their customers cannot adversly effect other customers by sending SPAM.  This requires regular maintenance and credible deliverability services.  It also requires ESPs to freeze accounts from customers who send SPAM.

In Conclusion

Ensure that your outgoing mail server is not listed in 75 of the most popular blacklisting services using Email on Acid’s deliverability tools. Make it to the inbox and look good doing it!

Most of the time, when the button is touched the remainder of the email is rendered. In other instances, we've seen it load a second portion of the email with no option for downloading the remainder. When the device is flipped from portrait to landscape the entire message shows, when it is flipped back the entire message remains - which leads us to believe that this is an iOS glitch.

Let's start with some examples:

Before (scroll to see button):

After tapping the button:

In this particular example, the only thing that is loaded from the beginning is the header image and the button appears well below the fold. Also, the email doesn't fully download after tapping the button. If you flip the phone to landscape view, it looks ok. If you flip it back, everything still looks ok.

Here it is when flipped:

Another thing to point out is that most of the original email was not loaded from the beginning. Therefore there's no content being displayed just under the subject line in the inbox:

This might cause people to avoid opening the email in the first place. Yikes!

If you'd like to see this in action on the iPad as well, here's the original HTML version.

So what's the fix?

1. Make sure that you have a minimum of 1,019 characters before your closing head tag (</head>) including spaces and carriage returns.
   
   If you don't have any need for more styles nor a style block, try inserting several lines of empty spaces.
   
   Strange right? This fixed the problem in each of the emails we tested. Oddly enough, I think 1,024 characters totals a single KB - so this might actually be caused by some type of iOS buffering issue.
2. If your email is below 10k, you can try removing all carriage returns and double spaces. We've seen instances where the download button no longer showed up if the email was at or below 7k. This option would by my last resort.

Here are some of the notes we took while testing just in case the above suggestions do not work for you:

1. The issue occurs with the exact same emails on the iPhone and iPad which leads us to the conclusion that it's an iOS thing, we tested in iOS4 and iOS5.
2. It's not sender specific - this eliminates issues with sender reputation.
3. It's not column specific.
4. It doesn't seem to have anything to do with nested tables.
5. Some tests that are over 25K render just fine yet others that are less than 10K cause the issue.
6. The amount that is left to download is not consistent in each of the emails that triggered the issue.
7. There's no clear reason why it gets cut off and from where within the email.
8. Doesn't seem to be due to meta tags, DOCTYPE, nor media queries. Note: When tinkering with these variables, you might create/resolve the issue because you are switching up the total number of characters before the closing head tag.
9. It has nothing to do with the internet service (ie: being temporarily interrupted).
10. There doesn't appear to be any caching - if an email is opened, then downloaded, the same issue will happen if the exact same email is sent again.
11. The date/time settings on each of my devices are correct.
12. I have seen people say that it happens when receiving mail on an Exchange account, I am using a POP3 account and I'm still seeing the issue.
13. It doesn't seem to be effected by images, I was able to recreate the issue with all images removed.
14. It is not caused by html entities (&nbsp).
15. I tried replacing all the content with Latin and that still didn't fix it - that rules out content.
16. It's not caused by empty table cells.
17. It's not a special character - I tried cutting/pasting into Notepad and then I resent the email.

In Conclusion

These days, it's hard enough to get your email to render correctly in each email client, yet alone having to worry about your message getting chopped off in two of the most popular mobile devices. If this happens to you and you find a different work-around, please don't hesitate to share your comments below! Or, if you are an iPhone/iPad user and you figure out a way to disable the download button, please share and we can update this blog post for others who are having the same issue.

Cheers and happy testing everyone!

<style type="text/css">
/*PLEASE NOTE: this has only been tested in native device 
email clients, not in device web browsers*/

/*Here are the device dimensions:
Iphone:  320px X 480px 
Smartphones: Vary from 240×320 to 720×1280
Android Phone (most popular): 350px X 480px
Additional Android Phones: 480×800 or 540×960
Xoom: 1280×800
Kindle Fire: 1024 x 600
iPad: 768 x 1024 */

    /*iphone, android, and most common smartphones --------*/
    @media only screen and (max-device-width: 480px) {
        body[yahoo] #desktop { display:none}
        body[yahoo] #ai { display:block !important}	
        body[yahoo] #smartphone { display:block !important}	
    }  		
    
    /*iphone only --------*/
    @media only screen and (device-width: 320px) {
        body[yahoo] #desktop { display:none}
        body[yahoo] #iphone{ display:block !important}	
    }  		
    
    /*kindle and iPad (portrait and landscape) --------*/				
    @media only screen and (min-device-width: 590px) and 
    (max-device-width:1024px){
        body[yahoo] #desktop { display:none}
        body[yahoo] #ki { display:block !important} 
    } 			
    
    /*kindle, iPad, and Xoom (portrait and landscape) --------*/				
    @media only screen and (min-device-width: 590px) and 
    (max-device-width: 1280px){
        body[yahoo] #desktop { display:none}
        body[yahoo] #kix { display:block !important} 
    } 								
    
    /*kindle (portrait) only ==> landscape is the default, 
    the portrait conditional is not supported.  If this device is 
    in landscape view, it will pick up on the iPad media 
    queries below---------- */
    @media only screen and (device-width: 594px) {
        body[yahoo] #desktop { display:none}
        body[yahoo] #kindle{ display:block !important}	
    }  										
    
    /* iPad only (landscape & portrait)----------- */										
    @media only screen and (min-device-width: 768px) 
    and (max-device-width: 1024px){         
        body[yahoo] #desktop { display:none}
        body[yahoo] #ipad { display:block !important}
    }   
    
    /* iPad (landscape only) ----------- */
    @media only screen and (min-device-width : 768px) 
    and (max-device-width : 1024px) 
    and (orientation : landscape) {
        body[yahoo] #desktop { display:none}
        body[yahoo] #ipad_landscape { display:block !important}
    }
     
    /* iPad (portrait only) ----------- */
    @media only screen and (min-device-width : 768px) 
    and (max-device-width : 1024px) 
    and (orientation : portrait) {
        body[yahoo] #desktop { display:none}
        body[yahoo] #ipad_portrait { display:block !important}
    }	
            
    /*xoom only*/
    @media only screen and (min-device-width: 1280px) 
    and (max-device-width: 1280px){
        body[yahoo] #desktop { display:none}
        body[yahoo] #xoom { display:block !important}
    } 				
</style>

...

<body yahoo="fix">
    <div id="kindle" style="display:none">Kindle Fire</div>
    <div id="ipad" style="display:none">iPad</div>       
    <div id="ipad_portrait" style="display:none">iPad Portrait</div>
    <div id="ipad_landscape" style="display:none">iPad Landscape</div>
    <div id="iphone" style="display:none">iPhone</div>
    <div id="xoom" style="display:none">Xoom</div> 
    <div id="ai" style="display:none">iPhone & Android</div>    
    <div id="ki" style="display:none">Kindle & iPad</div>        
    <div id="kix" style="display:none">Kindle & iPad & Xoom</div>
    <div id="android" style="display:none">Android</div>   
    <div id="smartphone" style="display:none">Smartphone</div>
    <div id="desktop">This is the desktop view</div>       
</body>

Note: in the above example we have implemented the Yahoo fix to ensure that the above styles are not picked up by Yahoo.

We recommend that you use media queries to re-purpose your images, showing and hiding divs as we've shown above has its limitations in Gmail and Outlook 2007/2010. The above example was inteded to showcase test samples, not nesessarily as a boilerplate and media queries for HTML emails should be handled with care.

Season's Greetings everyone! Here's wishing you an abundance of friends, laughter, prosperity, and family fun this holiday season from each and every one of us at Email on Acid!

VIEW GREETING ››

"Huh?" - our sentiment exactly, so let's dive straight into an example:

And here is your output in Yahoo!

As you can see, the first time the email is duplicated, it starts with the first instance of the address "Austin, TX 78713-7458". The second time it starts with "Texas 78713" which means that each instance caused a repeat.

I tried to narrow this down to a particular type of format which left me scratching my head even more. In fact, I later realized that it might only happen if you use 2 instances of the city and state. For example this will not cause a repeat:

But this will:

So what is going on here?

This seems to be caused by the pesky ruminants of Yahoo! Shortcuts, a plug-in that has been recently discontinued by Yahoo! Mail which once imposed random links from key words within your email. In reviewing the source code, it appears that Yahoo! Shortcuts is trying to geo code your address and although it does not insert an actual link anymore, something in the plug-in is causing everything else in your email to get duplicated.

We'd like to give a special thanks to Ryan Beavers and Sarah Sauer for helping us figure this out via our online forum thread!  Yahoo Displaying Emails Twice

What's the fix?

If this happens to you, the easiest fix is to spoof Yahoo! into thinking that your city and state are just another text string. To do this, you can add an HTML entity like "&#173;" in your address so that Yahoo! does not recognize it.

In the above example, we also inserted the same special character in front of each dash in the phone number to avoid issues in Gmail.

In Conclusion

This one topped the "strange" charts for us and that says a lot considering how many years we've spent testing HTML emails on various email clients and devices.  Hopefully Yahoo! will get around to fixing this bug soon.

Web Version
In the web version, Gmail will display a message that reads:

[Message clipped] View entire message

Clicking on the link will open your email in a new window.

Android
In the mobile version of Gmail for the Android - your email will just get cut off with the proverbial "..." Unfortunately there is no link for viewing the entire message. 

iPhone
In the mobile version of Gmail for the iPhone, you will see a message at the bottom of your email stating:

[Message clipped] Download entire message

After clicking on that link, it will re-open the email but you'll have to scroll all the way back down to place were you left off. Even after scrolling all the way back down to the bottom, my test email was not displayed in it's entirety.  Instead it was left with more dots "..." and no link to view more.

iPad
The mobile version of Gmail for the iPad does not appear to offer any links for viewing the entire message, instead the email is simply cut off.

In my initial testing, my HTML document did not contain any images, it consisted of mostly text with very little HTML coding.  I also tried this test with embedded images and concluded that since the images are not considered part of the original HTML content itself, they were not clipped nor did they effect the message of my email.  Instead, they were downloaded as one might expect after clicking on the "Show Images" link.

So what's the fix?

If you are close to 102K, you might save a few bytes by removing any unnecessary spaces, carriage returns or comments.

1.) You'll be sharing center stage with web based email clients like Gmail and Hotmail
Many web clients do not make use of iframes for displaying your email. Instead, you share the web browser with their interface and often times, they will do their best to ensure there's no conflict. That said, their interface often comes equip with lots of embedded styles, container elements (ie DIVs) and fancy client side scripts for displaying banners or cropping off a portion your beautiful email design.

2.) A random "</div>" can stick a wrench in Gmail and Hotmail
DIV's can be easy to mess up, especially if you have several nested so let's say you accidentally leave an extra </div> somewhere in your code... This will inadvertently close one of Gmail or Hotmail's UI div's and that can leave a big mark, especially if it's in the middle of your email design.

3.) Desktop email clients render errors differently
Each desktop email client uses a specific rendering engine. Unfortunately each rendering engine handles coding errors differently and some are more lenient than others. With that in mind, it's always best to test your email in the most popular web browsers first, then run an Acid Test to preview your email in the most popular email clients before sending.

4.) Empty TD's will get their fill from Gmail
Gmail doesn't like empty table cells so if you are trying to achieve a 1px space, you might get unexpected results. For example, this:

Will get converted to this:

5.) If you have random elements in your tables, Gmail will try to fill in the blanks
Let's say you have content that should be inside a table cell:

Gmail will wrap your random content inside table rows:

If you have more than one cell, it still renders only one new table row. For example:

Is converted to this:

If you have random text inside the TR but not in the TD Gmail will create a new TD.  For example this:

Is converted to:

In Conclusion

When you submit your email through our testing tool, the first thing we do is check for validation errors. This error report is based on your DOCTYPE. If we find anything, you can cancel out of the test, correct the issues, and re-run your email without charge.

Replacing and/or re-using graphics is a great place to start for a few different reasons:

iPhone
The iPhone scales your email down by default so that the widest element in the email fits within its viewport. From there, the user must scale it back up (outward pinch) in order to read it.  After scaling up your email, they will be forced to scroll left and right to read each line. By resizing your widest graphic and/or HTML container, you can control the size of your text at first glance.

Android
The Android handles text readability much differently. In this device, your text (usually) wraps within the center viewport and the rest of the graphics and/or HTML containers can be scrolled from left to right. Therefore, important messages often get cut off to the right of the viewport window. Check out our Android demo to see what I mean.

Code Examples

Using media queries, you can control the way various page elements render in the iPhone and Android. Here are a few examples for handling images:

1.) Re-size and re-use the same image (better for overall file size):

<style type="text/css">
   @media only screen and (max-device-width:480px;) {
      body[yahoo] .header { width:300px}
    }
</style>

<body yahoo="fix">
    <img src="http://www.url.com/image.jpg" class="header" width="600" height="100" />
</body>

2.) Completely replace your image(s):

<style type="text/css">
    @media only screen and (max-device-width:480px;) {
        body[yahoo] .mobile_only {
           width:600px !important;
           overflow:visible !important;
           float: none !important;
           display: block !important;
           }
        body[yahoo] .desktop_header { display:none}
        }
</style>

<body yahoo="fix">
    <div class="mobile_only" style="width:0px; overflow:hidden;float:left;display:none">
       Image for mobile - width="300px":
      <img src="http://www.url.com/image1.jpg" width="300" height="100" />
    </div>
    <div class="desktop_header">
        Image for desktop  - width="600px":
        <img src="http://www.url.com/image2.jpg" width="600" height="100" />
    </div>
</body>

Important: We used overflow, width and float above because Gmail does not support the "display" property if the value is set to "none."  We left the display:none in there for all other clients.

We also incorporated this Yahoo fix in both examples.

Depending on the response, we have some big ideas for this site so don't hesitate to share your feedback or suggestions below!

HTML Email Boilerplate

A little while back, Sean Powell came up with a brilliant idea for developing an email boilerplate. It's an HTML template that is stripped of any design, but contains recommendations for DOCTYPE, embedded CSS, and sample HTML coding for tables and text links. We liked the idea so much that we reached out to Sean in an attempt to collaborate and we just launched an updated version on Emailology.org.

This boilerplate is jam packed with additional features like setting universal fonts, using background images, bulleted lists, media queries for mobile devices, embedding video and much more. It serves as a great starting point for any email job and will save you loads of time when testing.

Email Client Tips & Tricks

We included our popular email client tips & tricks on this initial release of Emailology. This is an organized collaboration of common questions and quick fixes for issues you might face when developing HTML emails.

We'd like to send a special thanks to all of the people who have submitted questions and answers via our Acid Test and in our community forum! We sincerely hope other developers who follow in your footsteps will find this resource useful!

Universally supported HTML/CSS

Based on our code analysis research over the past three years, we've published a standards guide for universally supported HTML and CSS. This is a great resource if you want to play it "safe" when developing HTML emails. We included Lotus Notes 6.5 and 7.0 in our list of supported clients but since they are less popular, you have the option of turning them on or off.

Special Character Conversion

Based on our popular blog article regarding special characters in HTML emails, we've included a free tool that converts each of your special characters to HTML entities. This will ensure that your text renders as intended no matter what content-type is imposed upon your email.

As mentioned above, we have some big plans for this site so be sure to share it on Twitter, Facebook, and Google's +1. Or if you are feeling really generous, post an article about Emailology on your blog and we will gladly hook you up with some free test credits if you need them!

In the desktop version, the link opens Google's new voice/chat console which is displayed along the right column of the Gmail interface.

In mobile versions, the link opens up the mobile phone console with your phone number pre-populated making it very easy to dial numbers directly from your email.

Each of the following formats will get converted to links:

So how do you get around it?

1.) Use an HTML entity in your phone number that Gmail does not recognize:

In the example above I used the following entity just before each dash: "&#173;"

In the example above I used: "&shy;"
Unfortunatly, this HTML entity renders a dash "-" in Lotus Notes 6.5 and 7 (only) so the phone number appears like this: 212--389--3934

2.) Wrap an anchor tag around the phone number with an inline style that matches the rest of your text:

3.) If it's possible, use the text version of the phone number:

If you can find any additional ways to bypass the text links in Gmail, don't hesitate to share them below!

For example:

Will get converted to this:

What's the fix?

Simply use hexadecimal values instead:

RGB decimal values are supported in embedded styles so another possible fix is to use embedded styles but this won't work in Gmail.

For example:

I tested this using the color and background CSS properties within several various HTML tags. This is particularly important if you use WYSIWIG editors when developing HTML emails.

So what causes the yellow box?
If your email exceeds the reader's browser window width minus 370px, your email will get cut off along the right side and the yellow box will appear.

Here's an example before:

If you click to "Show full message" your email will be displayed at its intended width and a horizontal scroll bar will appear along the bottom of the browser window.

At this time, I don't have a suggested work-around, aside from keeping your email under 630px wide. This would presume that your average user will have their browser window sized to at least 1000px wide.

I tested this using images, DIVs and tables in Firefox 4.0 and IE 9.

We want to do this email campaign and it's going to be wildly successful! What do you mean? Of course it should render properly, that's a given. SPAM? That shouldn't be a problem, these people have subscribed to our list!

Meanwhile your mind is racing at the vast complexity of this seemingly simple task.

We all know that there should be a universal standard for HTML and CSS but the fact is email clients are far less concerned with compliance than web browsers. None of their users are complaining about the way advisements are rendered in their inbox. So can we make a difference? It may be wishful thinking but our answer to that question is: Yes!

Email Standards Project
A few years ago, Campaign Monitor launched the Email Standards Project. It's a site that identifies current standards with a rating system for each email client. Their ultimate goal was to build a community dedicated to making a change.

Fix Outlook Campaign
Soon after Campaign Monitor launched the "Fix Outlook" campaign - a Twitter based platform wherein people could tweet on behalf of fixing Outlook 2007. The goal was to get Microsoft to use an engine like Internet Explore vs. Microsoft Word in its next release. Although Outlook 2010 showed no signs of compliance, Microsoft has recently released that Outlook 2011 for the Mac will be using Webkit.  Congrats Campaign Monitor! We applaud you for taking initiative and starting a movement!

Blogging for Change
Since starting our blog in 2009, we have also made some subtle strides at increasing compliance. In November 2010, we reported that images were not supported in the iPad version of Gmail. Within two days a representative for Gmail responded and notified us that it had been resolved.  Though our post was likely just an asside, it's good to know that they are listening in on conversations regarding email renderability.

Just recently, we published an article regarding Hotmail's latest release and the fact that they no longer support image maps. Within a week, they responded and again the issue was resolved immediately.

It may be optomistic but we have to believe that email clients are just as concerned with overall customer satisfaction as the next company. We are behind Campaign Monitor 100% when it comes to their visionary effort to bring universal standards to email developers worldwide! 

Emailology.org
With that in mind, we've just launched a new project called Emailology - the science of looking good in the inbox. There, you will find a guide for universally supported HTML/CSS and several other handy tools for developing HTML emails.

It may be a rough road ahead but until we start to see standards emerge, we are committed to help you navigate your "not so simple" task of developing and delivering HTML emails that render flawlessly across the board.

After numerous installs and uninstalls, we concluded that when Outlook 2003 is installed for the first time, it uses the version of IE that is installed on that particular OS as it's rendering engine. From there, if IE6 is upgraded to IE7, Outlook will still use the original version of IE (in this case IE6).

This means that there are ten possible variations effecting the way an email might render in these two email clients:

Currently, we provide screen captures for Outlook 2003/IE8 and Outlook Express/IE8. However, from my recent research, Outlook 2003 was released on October 21, 2003 with MS Office 2003.  IE6 was released on August 27, 2001 and IE7 was released on October 18, 2006. That said, we have discussed the possibility of adding an Outlook2003/IE6 configuration because that was the most popular browser during the time of its release.  Interestingly, Outlook Express was released back in 1999 at which time IE5 would have been the most popular version of IE.

We'd like to hear your thoughts on this subject! Let us know which configurations you would like us to add next.  Feel free to post a comment (below) or speak your mind on Twitter: @emailonacid.

In completing this process, we were forced to make some DNS changes. We made those changes on Friday night which is our slowest time of the week. It generally takes between 2 to 48 hours DNS changes to propogate. That process has been completed but some people are reporting intermittent issues when trying to view our website. This is most likely caused by DNS caching.

If you receive a 401 error or you see our maintenance screen, try clearing your DNS cache:

Windows:

Go to a command prompt and type: ipconfig /flushdns

Mac:

Go to the terminal and type: dscacheutil -flushcache

Linux:

In Linux, the nscd daemon manages the DNS cache. To flush the DNS cache, restart the nscd daemon. To restart the nscd daemon, use the command `/etc/init.d/nscd restart`

As always, don't hesitate to contact us if this does not resolve your issue and stay tuned for more specifics regarding our new infrastructure.

In an effort to express how grateful we are for your patience and understanding, we will be extending each Email on Acid subscription by 4 days.  This means if your subscription was set to renew on the 5th day of this coming month, it will now renew on the 9th day and all subsequent renewals will be based on that date.  If you are on a 3, 6, 9 or 12 month plan, your auto renewal will also be extended 4 days.

We will follow up with a blog article that further explains the infrastructure changes that we have made to ensure that it does not happen again. We hope that this level of transparency will provide peace of mind to those who have entrusted us.

With humble sincerity,
Your friends at Email on Acid

For those of you who are not aware, our near perfect, 98% uptime track record came to a screeching halt when our systems went down for just over 40 hours this past weekend. We agree that this type of incident is completely unacceptable.

Yesterday, we posted a blog article keeping our users informed of our progress in getting the site back online. At that time, we were using a backup server to host our content management system. Now that we've switched to our production server, that post is no longer viewable. We plan to retrieve it but this is a low priority compared to keeping our site up and getting a backup server in place. In no way are we trying to hide the fact that we were down.

Today, our technicians are still very much entrenched with getting a fresh, new server up and configured. From there, they will be implementing a new infrastructure that will ensure that this never happens again.

During our data recovery process, there might still be some corruption. We are trying to isolate and resolve those problems as they come up. Feel free to post comments to this blog if you notice anything out of the ordinary. We will be sure to respond as quickly as humanly possible.

Styling the Header and Footer

We realize that people are less likely to download images from automated emails so we wanted the header and footer to flow with the design either way. This technique works for most of our targeted email clients so for us, it's well worth the extra effort.

We started with a nested table for the header (carriage returns are removed for IE):

We intentionally left out the width and height attributes for the image so that the green bar does not render as a grey box in Hotmail/Firefox and Outlook 2007/2010.  We also didn't want to take up too much vertical space for the footer when images are hidden so we used the same treatment for that as well.

Here are the final results:

Styling the Button

We also wanted our "Online Demo" button to render correctly no matter what.  Once again, we started with a nested table and used the background attribute from within it's TD.

Here are the final results with images blocked:

Here are the results with images showing:

Creating the Mobile Version

Last but not least, we created a toned down version for our mobile viewers. 

Here is the original email:

Here is that same email for Android and iPhone users:

Here is the media query we used to achieve this affect:

As you can see, we resized the container tables and each of the header and footer images via CSS.  In this case the CSS trumps all of our preset HTML attributes.  We also adjusted the headline to be a bit smaller and hid some of the "added bonus" items.

In case you were wondering, we used attribute selectors in our media queries to ensure that Yahoo does not render our mobile version.  Click here for more info.

So for example, this:

Will get converted to this:

The Fix

Copy your style block to just before the closing body of your email:

Up until now, I was convinced that placing the style block in the body tag was an email folklore; the legend of a day long ago when that fix actually worked for Gmail.  Nevertheless, I think the reason that this works is because of the way Yahoo is formatting it's closing style block.  Moving the block to just below the opening body gave me inconsistent results.

Will get converted to this:

As you can see, Yahoo! converts each of your style names into a name that is unique to your email. They do this in order to keep your styles separate from the ones they use in their interface. So later in the document, it also converts your HTML:

Is converted to:

Although Yahoo! has really good intentions, I think the problem is occurring because their parsing tool does not take into account media queries and the way they are formatted.

So what's the fix?

Campaign Monitor came up with a sneaky solution to use attribute selectors since they are not support either.  That way your media query and the styles within will not get picked up by Yahoo!

To give an example, if I convert my original query from above, it would look like this:

Another option is to use attribute selectors a little differently wherein you add a "*[class]" before all class declarations and "*[id]" before ID's like this:

The bugger about using the examples above is that each element controlled within your media query must contain an HTML attribute (id, class, style, etc). Unfortunatly, universal, type and decendent selectors are out of the question.

So here's one more creative tactic that gives you access to additional selector types:

In this example, I am making up a "yahoo" attribute and placing it in the body tag.  I could have left out the value "fix" but this will help me remember what it's for later on.  Then I am placing "body[yahoo] " before each declaration which now allows me to access universal selectors.

Each of the recommendations above will work in both Yahoo! Classic and Yahoo! Mail.

In a recent article: Media Queries in HTML Emails, we explore which devices support media queries. To take it a step further, here's your play by play approach to developing your email for the iPhone, iPad, and Android devices.

First we need to set up your media queries to detect the user agent:

<style type="text/css">
@media only screen and (max-device-width: 480px) {
    /* Here you can include rules for the Android and iPhone 
    native email clients. 
    
    Device viewport dimensions are as follows:
    Iphone:  320px X 480px - portrait, 480px X 320px - landscape
    Android:   350px X 480px - portrait, 480px X 350px - landscape
    (These are average dimensions, the Android OS runs on several different devices)
    */
}		
@media only screen and (min-device-width: 768px) and (max-device-width: 1024px){
    /* Here you can include rules for the iPad native email client. 
    Device viewport dimensions:  768px x 1024px - portrait, 1024px x 768px - landscape
    */
}
</style>

Important: I have included some notes in this snippet but be sure to strip out all of the CSS comments to avoid getting blocked by SPAM filters.

What happens next depends on your layout.

As a general rule, it's better to add "bells and whistles" to your media queries which optimize your layout in mobile devices. In other words, resize some images, text, and maybe even throw in a few background images for good measure.

However, if you want to get really crazy, there is one more option: Let's say you have a three column layout and you want it to appear as two columns in the iPad and one column in the Android & iPhone. To do this, you could show and hide container DIVs depending on the device.

I tested this out and Lotus Notes 6.5 and 7 were the only clients that do not support the "display" property, instead they display all DIVs as "display:block" by default. However, if you feel that your open rates in mobile devices outweigh the risk of leaving old versions of Lotus Notes in the dust, here is a working example for you:

<style type="text/css">
@media only screen and (max-device-width: 480px) {
    body[yahoo] #smallScreen {display:block !important}
    body[yahoo] #desktop {display:none !important}
}	
@media only screen and (min-device-width: 768px) and (max-device-width: 1024px)  {
    body[yahoo] #largeScreen {display:block !important}
    body[yahoo] #desktop {display:none !important}
}	
</style>

</head>
<body yahoo="fix">
    <div id="smallScreen" style="display:none; color:#FFF; background:#000;">
    	This is a Small Mobile Client
    </div>
    <div id="largeScreen" style="display:none; color:#0F3; background:#FFC;">
    	This is a Large Mobile Client
    </div>
    <div id="desktop" style="display:block; color:#00F; background:#3F3;">
    	This is a Standard Desktop Client
    </div>
</body>

There are a few downsides to this approach.  First, you might end up having to duplicate some content here and there.  Secondly, even though you are hiding two DIVs in this example, the email client will still have to load up all of your HTML and assets.  So you might consider reusing all of your images in each instance to control the overall file size of your email.  To be more specific, let's say you are using an image at full size for desktop clients, just resize that same image for mobile devices using CSS within your media query.  A big thanks to Jeff Doan for bringing this loading issue to our attention on Twitter!

Update October 14, 2011
It was just brought to our attention that Gmail does not support the inline display property if the value is set to "none".  Here's the forum thread and a possible work-around if you are determined to show/hide specific elements for desktop vs. mobile devices: Hiding content from desktop view, but showing it on a mobile device

As you may know, Yahoo! Mail ignores the media query conditinal statement and reads your styles as if they are outside of the query.  So for this example, I am using attribute selectors in each media query declaration.  A big thanks to Campaign Monitor for posting this fix a few months back!  Here is our follow-up article which further explains the Yahoo! strategy I used above.

As a side note: the Android device does NOT support class declarations in embedded CSS outside of the media query.  Keep that in mind as you construct the rest of your embedded CSS and use IDs or type selectors whenever possible.  Here's more on that topic.

After logging into Yahoo!, here's what you will see if you haven't upgraded yet:

At this time, they still support Yahoo Classic, which aside from its support for embedded styles is very similar to Gmail.

With Yahoo! Shortcuts out of the way, controlling your link colors is much easier.  To do so, we recommend that you start by adding this to your embedded css:

The color used above is the pre-established link color for Gmail. This will overwrite Hotmail and Yahoo Beta's embedded link colors and make it consistent with Gmail. From there, you must overwrite this color inline:

The inline declaration for "text-decoration:none" is optional and is only required for Gmail. You can overwrite it in your embedded CSS for all other clients.

Here's to being out with the "New" and the "Beta" and being in with just pain old "Yahoo! Mail!"

1.) Hotmail no longer supports image maps

I tested this in every browser and did some digging to see what's going on behind the scenes. Turns out, they are blocking the onclick event via Javascript. Rollovers for the alt, title, and href remain intact but when you click on the link from within the image map, it does nothing.

Since Hotmail does not support Javascript within HTML emails, there's no way to prevent this functionality. If you want individual sections of your image to be clickable, you are going to have to slice it into multiple images and use a table to align the pieces.  Don't forget about our image spacing work-arounds to ensure they line up evenly in all browsers.

I am not sure how long the map tag has been in existence but developing HTML emails just got a little bit harder. A big thanks to Justin Tiernan for bringing this to our attention via our online forum!

2.) Linked images don't work in Internet Explorer 7 & 8

We've also seen some buggy stuff happen when linking images in IE8. For example:

<a href="http://www.emailonacid.com" target="_blank">
	<IMG src="http://www.emailonacid.com/test.jpg"  />
</a>

When you click on the image the browser opens the link and then immediately jumps back to Hotmail. Depending on the target, it will jump back to the inbox or the original message. This ONLY happens the first time you open the email. If you re-open the email, click on the exact same link, it opens in a new window.

IE9 opens the URL in a new tab (as one would expect). This issue does not seem to effect text links.

Unfortunately I am at a loss for offering a potential fix on this one.

3.) Hotmail's latest release is incompatible with certain browsers

We've found several instances where Hotmail does not work in certain browsers depending on local configuration and plug-ins. For instance, when I click on inbox items in Chrome 12, nothing happens. For a complete list of bugs that they have identified and are working to resolve, check out the following link:
http://www.windowslivehelp.com/thread.aspx?threadid=18cc170e-0374-423e-aab7-eb56465c8557

With that said, we've recently added support for Mozilla, Webkit and Microsoft CSS extensions (for example: -moz-outline-radius, -webkit-border-radius, and -ms-text-justify). To learn more about the various CSS browser extensions that are available, feel free to check out these resources:

• Mozilla CSS Reference
• Microsoft Extensions
• Dottor Web Reference

Here is what our research showed:

Next we are moving on to HTML 5 and CSS3 - Stay tuned for our results!

Although AOL offers fantastic support for WC3 standards, they've made some recent updates that effect your body styles and attributes.

First, it completely replaces your body tag. For example:

<body style="background:#000; min-height:2000px; color:#fff; padding:15px">

Get's converted to:

<body style="background-color: white;font-family: Arial,sans-serif;font-size: 10pt;border: 0px;">

Second, it ignores your "body" type selector within your embedded CSS. For example:

<style type="text/css">
	body {
        background:#000; 
        min-height:2000px; 
        color:#fff; 
        padding:15px
    }
</style>
<body>
	Your content...
</body>

Get's converted to:

 <body style="background-color: white;font-family: Arial,sans-serif;font-size: 10pt;border: 0px;">
     <div id="AOLMsgPart_UniqueID">
         <style type="text/css">
         	#AOLMsgPart_UniqueID body {
                    background:#000; 
                    min-height:2000px; 
                    color:#fff; 
                    padding:15px
                    }  
         </style>
         
         Your content...
         
     </div>
 </body>
 

Since this is looking for a body within the AOLMsgPart div, it doesn't pick up your styles. I tried inserting a second body tag just to see what happens but AOL ignored it. I also tried a few other CSS Attribute Selectors but since AOL inserts it's own uniqueID for the div containing your email and it is separated by an underscore, there is no obvious way to hack it.

The Solution

Your best bet is to use a wrapper element like a span or a table with inline or embedded CSS properties. In a recent blog post we provide a great example of this solution which has been tested in all email clients: Background Colors in HTML Emails.

In my last article I explained why the large, horizontal gap sometimes appears in Outlook 2007 and 2010. Unfortunately the only perfect fix is to stack your tables so that you never have a table that exceeds 23 inches in height. One common strategy for setting a background color for all email clients is to create wrapper table with a width of 100%. This makes it challenging to keep your tables under 23 inches in height - especially when developing long newsletters. With that said, here's another option you might consider...

Here it is, short and sweet:

<html>
<head>
    <style type="text/CSS">
        body, #body_style {
            background:#000; 
            min-height:1000px; 
            color:#fff; 
            font-family:Arial, Helvetica, sans-serif; 
            font-size:12px;} 
         
        .ExternalClass {width:100%;}
        .yshortcuts {color: #F00;}
        p {margin:0; padding:0; margin-bottom:0;} /*optional*/
        a, a:link, a:visited {color:#2A5DB0;} /*optional*/
    </style>
</head>

<body style="background:#000; min-height:1000px; color:#fff;font-family:Arial, Helvetica, sans-serif; font-size:12px" alink="#FF0000" link="#FF0000" bgcolor="#000000" text="#FFFFFF"> 

	<span id="body_style" style="padding:15px; display:block"> 
    
		Insert your body copy and nested tables here. <br />
        <a href="http://www.emailonacid.com" style="color:#F00">www.emailonacid.com</a> 
        
            <table bgcolor="#000000" width="600">
              <tr>
                <td>Content</td>
              </tr>
            </table>
          
    </span>

</body>
</html>

Let's Break this Down...

1.) DOCTYPE

I recommend testing in all browsers without a DOCTYPE because most email clients will strip it out. Read more on this.

2.) Embedded Body Properties

	body, #body_style {
        background:#000; 
        min-height:1000px; 
        color:#fff; 
        font-family:Arial, Helvetica, sans-serif; 
        font-size:12px;}  

The "body" is defined here for Yahoo Beta because it does not support your body tag. Instead, it will create a wrapper div around your email and that div will inherit your embedded body styles.

The "#body_style" is defined for AOL because it does not support your embedded body definition nor your body tag, we will use that later as our wrapper.

The "min-height" attribute in this case is used for AOL so that your background doesn't get cut off if your email is short.

Random fact: If you include any single quotes in your CSS comments your entire email will appear blank in Entourage 08. This tidbit had me stumped for quite a while.

3.) Recommended Default Styles

	.ExternalClass {width:100%;} 
	.yshortcuts {color: #F00;}
	p {margin:0; padding:0; margin-bottom:0;} /*optional*/
	a, a:link, a:visited {color:#2A5DB0;} /*optional*/

The .ExternalClass is used for Hotmail and ensures your email will take up the entire width of its viewing pane.

The .yshortcuts {color: #F00;} is for Yahoo Classic and Yahoo New. Set this to be the color you prefer for your links.

By default, I reset the padding and margin for my email to "0". This forces me to do all of my spacing inline. This also overwrites Hotmail's default CSS: p {margin:0 0 1.35em}. Since Gmail doesn't support embedded CSS and it uses default browser margins for paragraphs, I always include a "margin=0" inline as well. From there I do all of my paragraph spacing with padding for a few reasons:

1. Hotmail does not support the "margin" nor the "margin-top" properties and
2. Outlook 2007 and 2010 offer better support for padding in block elements

Gmail uses #2A5DB0 as its default color for anchors. This is another style I don't allow myself to change because it forces me to overwrite my link colors inline.

4.) The Body Tag

<body 
style="background:#000; min-height:1000px; color:#fff;font-family:Arial, Helvetica, sans-serif; font-size:12px" 
alink="#FF0000" 
link="#FF0000" 
bgcolor="#000000" 
text="#FFFFFF"> 

I included the style attribute for Gmail, it does not support embedded CSS and will convert this body tag to a div and maintain its inline styles. Since it gets converted to a div, the other body attributes like bgcolor are ignored.

I included body attributes (alink, link, bgcolor and text) for Lotus Notes 6.5 and 7, as these clients do not offer much support for embedded nor inline CSS.

The "min-height" attribute is set for Gmail and AOL since they will be converting your body to a div.

5.) The Span Wrapper

	<span id="body_style" style="padding:15px; display:block"> 

This span is working as a wrapper and is required for AOL. You can use any inline html element but it must be a standard element. For example, a custom tag like <aol_body></aol_body> will not work.

Since Outlook 2007 and 2010 ignore the display:block in this span, it will not create unwanted horizontal gaps (as long as you do not have a table in your email that exceeds 23 inches in height).

6.) The Table

<table bgcolor="#000000" width="600">
  <tr>
    <td>Content</td>
  </tr>
</table>

Here's where you would stack your tables, I threw in a bgcolor and width attribute for the Android Gmail application. As I have mentioned many times prior, Gmail converts your body to a div, even on mobile apps. Since there is no width set in your body, the Android sets the width of your converted body tag to that of the device viewport. To make a long story short, your background color will get cut off unless you add it to each of your tables as well.

Random fact: At least one "<table" or "<img" text string must be in your HTML code in order for Entourage 04 and 08 to process your embedded and inline CSS. This is especially important if you rely on divs only.

I tested this in the following email clients:

• Android Gmail
• Android Mail
• AOL
• Entourage 04
• Entourage 08
• Gmail
• Hotmail
• iPad
• iPad Gmail

• iPhone
• iPhone Gmail
• Live Mail
• Lotus Notes 6.5
• Lotus Notes 7
• Lotus Notes 8
• Lotus Notes 8.5
• Mac Mail
• Outlook 2003

• Outlook 2007
• Outlook 2010
• Outlook Express
• Thunderbird2
• Thunderbird3
• Windows Mail
• Yahoo Beta
• Yahoo Classic
• Yahoo New

We'd like to offer a special thanks to Adam Naisbitt from EasyBlast.co.uk for helping us troubleshoot and collaborate on possible fixes. Thanks Adam, it's people like you who keep our developer community going strong!

The Cause

As we all know, Outlook 2007 and 2010 use the Microsoft Word rendering engine for displaying HTML emails. The desktop application of MS Word allows you to choose from a few different layout views but Outlook uses the "Web Layout" view which is much like a WYSIWYG editor because it outputs its own HTML code. Within its viewer, it uses "text boundaries" which differ slightly from "page breaks." When Word interprets a page break, it actually inserts a <BR /> tag in its HTML output. Text boundaries are used to separate elements within the web layout for purposes of printing and don't actually output any HTML code.

From our research, we learned that text boundaries stretch to a maximum height of 23.7 inches (aprox. 1,790 pixels) before it automatically inserts a partition line and creates a new text boundary. Therefore, If you have any tables that are higher than 23.7 inches within your email, it will get broken up into multiple, stacked text boundaries.

Most often the contents from one text boundary to the next is flush and therefore unnoticeable. However, when you do find unwanted spacing, you might be in for lots of fine tuning before you get it resolved.

Automatically generated text boundaries always render at the same height so if you have a table with a width of 100% of the view pane and your content flows accordingly, the location of the actual partition line will be dependent on the size of the viewer's window. Also, I was primarily testing with Outlook 2007, part of Microsoft Office Enterprise 2007. The maximum height of text boundaries may vary from one version of Microsoft Office to the next.

From what I can tell, there is no way to disable or increase the maximum height for text boundaries. In fact, I was really hoping to find a document specific property in the HTML output because that might have led way a possible hack. In all of the documentation I have found, even from Microsoft, they imply that the maximum document size is a hard, fast rule and there is no getting around it.

Here are some instances that might cause the spacing:

1.) A table with two or more columns that stretch longer than 23.7 inches in height.

2.) Nested tables within a large containing table.

3.) Tables that are reliant on rowspans that exceed 23.7 inches in height.

4.) A large image that is placed at or around the 23.7 inch border might get bumped up or down from one text boundary to the next causing lots of unwanted spacing. In fact, I also tested images that where larger than 23.7 inches and the Word viewer essentially resizes the image to a proportion that fits within the text boundary. So if you insert really tall spacer gif, for example, it will get placed into one of the text boundaries and will be resized within that boundary's height constraint.

There may be several other instances that cause the gap, if you come across one that hasn't been listed here, please let us know about it, we'd be happy to look at your HTML code.

So what is the solution?

Generally speaking, I recommend testing your email first to see if text boundaries are causing spaces. As I mentioned, many times the table looks fluid, no matter how many nested tables you may have. If you do see a space, here are some things you can try:

1.) The best solution is to break out your tables into two (or more) stacked tables that are less than 23.7 inches in height. A new text boundary is created every time you create a new table element so one table might be 10 inches and another might be 15 inches. As long as each individual table does not exceed the height constraint you won't end up with automatically generated text boundaries.

Use nested tables within each stacked table but be aware of the fact that some of your nested tables might be over 23.7 inches in height. With that said, you could start breaking those apart first and test between each iteration.

When doing this, you might have to remove all spaces and carriage returns within your code, particularly between your closing and opening tables. This helps to ensure that they stack on top of each other perfectly.

Since this may cause a complete restructure of your table layout, it's a good idea to get in the habit of designing your tables so that they can be easily stackable when needed. You might only have to break apart one table that exceeds the maximum height, others might not cause a noticeable gap.

If you are using a wrapper table to control the background color of your email try using a span with "display:block" instead. Click here for an explanation on that.

2.) Try setting a break right BEFORE the spacing, using style="page-break-before: always".

For example, if the issue is right on a certain table row, then make that <tr> into:

A big thanks to MiketheCoder for this recommendation! Here's the full article: Outlook 2007 Screws up spacing where page breaks would appear

3.) Add a "height" attribute in the TD that is getting broken. Sometimes this can limit the amount of spacing.

<td height="2000">

4.) You can try inserting breaks or paragraph tags strategically in order to match up each column of your table so the text boundary appears seamless. 

<p style="height:10px; margin-bottom:0; margin-top:0; padding:0">&nbsp</p>

It is important to break out margin-bottom and margin-top here because Hotmail does not support the generic "margin" property. Since this can be tricky and your content is bound to change, this option is less ideal.

5.) You can try adding content to the section above the forced break to push the content down and avoid the break - but this is also not ideal as you might not be in charge of the content within the email.

I have read from other blogs and resources to avoid using more than 3 nested tables in Outlook 2007 and 2010 but I have yet to prove this theory. Many times, if you remove nested tables, you are actually removing a table that exceeds 23.7 inches so this might be why it has worked for others in the past. Again, if you have more examples or information to share, don't hesitate to reach out to us and shed your wisdom on the subject.

If you have gotten in the habit of inserting wrapper tables with a width of 100% for purposes of adding a background color, this might cause your table to be over 23.7 inches. I wrote a follow up article on ways to achieve the same effect in every email client without having to use a wrapper table: Background Colors in HTML Emails.

For example, this:

<body>
  Content
</body>

Will get converted to this:

<body>
   <div class="tripane content">
     <div class="msg-body inner undoreset">
     <div>
        Content
     </div>
   </div>
<div>
</body>

Here are the styles that Yahoo Beta uses with regard to those two divs:
(for simplicity, I have displayed only relevant styles)

.tripane .inner{margin-left:10px;}
.tripane .msg-body{margin-left:29px;}
.message .inner p, .tripane .inner p {line-height: normal;}
.undoreset strong, .undoreset th {font-weight:bold;}
.undoreset em, .undoreset address, .undoreset caption, .undoreset cite {font-style:italic;}
.undoreset table {display:table;border-collapse:separate;}
.undoreset tr {display:table-row;vertical-align:inherit;}
.undoreset td {display:table-cell;border-spacing:2px;border-collapse:none;}
.undoreset th {display:table-cell;vertical-align:inherit;font-weight:bold;padding:1px;border-collapse:none;}
.undoreset p {display:block;margin:1em 0;}
.undoreset blockquote {display:block;margin:1em 40px;}
.undoreset address {display:block;font-style:italic;}
.undoreset center {display:block; text-align:center; text-align:-moz-center; text-align:-webkit-center;}
.undoreset h1, .undoreset h2, .undoreset h3, .undoreset h4, .undoreset h5, .undoreset h6 {display:block;font-weight:bold;}
.undoreset h1{font-size:2em;margin:.67em 0;}
.undoreset h2{font-size:1.5em;margin:.83em 0;}
.undoreset h3{font-size:1.17em;margin:1em 0;}
.undoreset h4{margin:1.33em 0;}
.undoreset h5{font-size:.83em;margin:1.67em 0;}
.undoreset h6{font-size:.67em;margin:2.33em 0;}
.undoreset ol,.undoreset ul{display:block;padding-left:40px;margin:1em 0;}
.undoreset ul{list-style-type:disc;}
.undoreset ol{list-style-type:decimal;}
.undoreset li{display:list-item;}
.undoreset pre,.undoreset code{display:block;font-family:Courier New;white-space:pre;margin:1em 0;}
.undoreset a, .undoreset a:hover{text-decoration:underline;}
.undoreset div p{margin:0;}

Overwriting These Styles

You have many options for overwriting these:

1.) Use embedded CSS. For example:

<style>
   p {margin:0}
   h1 {font-size:20px}
   .mystyle div {margin:0}
   .headers {font-size: 15px}
</style>

2.) Do everything inline. For example:

<p style="margin:0"></p>
<h1 style="font-size:20px"></h1>
<div style="margin:0"></div>
<span style="font-size:15px"></span>

Yahoo Beta strips your entire body tag along with each of its attributes.

For example, this:

<body style=" background-color: #CEE2DF">..

Will get converted to this:

<body>
   <div class="tripane content">
     <div class="msg-body inner undoreset">
       <div>...

To get around this, you can define your styles in the "body" type selector in your embedded CSS. From there, Yahoo Beta will convert your embedded body styles to inline and place them inside the div it creates around your email content.

For example, this:

<style>
   body {background-color: #CEE2DF}
</style>

<body>...

Will get converted to this:

<body>
  <div class="tripane content">
    <div class="msg-body inner undoreset">
      <div style=" background-color: #CEE2DF">...

Bada bing right? But wait, there's more to this one...

Let's not forget that Gmail does the EXACT opposite. As many of you already know, Gmail does not support embedded CSS and it also converts your body tag to a div. Gmail is different from Yahoo Beta because it actually acquires your body attributes into the div that it inserts.

For example, this:

<body style=" background-color: #CEE2DF">

Will get converted to this:

<div style=" background-color: #CEE2DF">

So the best solution in this case is to use embedded CSS AND inline styles for your body, for example:

<style>
  body {background-color: #CEE2DF}
</style>

<body style=" background-color: #CEE2DF">...

This solution should work for all of the email clients that we currently support.

One last thing to consider...

Obviously divs operate a little differently than a body tag, especially when it comes to background colors and images. Since your content will get placed inside a div, you might want to add a min-height to the mix:

<style>
   body {background-color: #CEE2DF; min-height: 700px}
</style>

<body style=" background-color: #CEE2DF; min-height: 700px">...

So what's with all the other divs that Yahoo Beta is inserting? Click here to learn more about how they might affect your layout.

One of the more critical conversions that you should be aware of is that Outlook 2007 and 2010 will often move your CSS from div's and headings into nested paragraph and spans. Sometimes, it keeps the outer container, other times it eliminates it entirely.

For example this:

Will get converted to:

The Problem

As you can see, this conversion moved our CSS from its original box element container to an inline SPAN element and the padding was ignored.

Solutions

One work-around is to avoid padding in block element containers and use margins instead.

Note: I did not include the "margin" nor "margin-top" properties in this example because they are not supported by Hotmail.

After extensive testing, we have confirmed that the padding property is supported in TD's. So another fix is to move your padding into the containing TD, for example:

A few months ago, we started researching which mobile email clients support media queries. For those who have never used them before, media queries allow you to control the layout of your email based on the mobile device that is being used to open it. They can be either linked or embedded within your style block. Here's an example:

Media queries support boolean conditional statements that are true or false based on the type, resolution and/or size of the device. For example, 'screen' and 'print' are examples of media types whereas 'device-width', 'min-device-width', and 'max-device-width' are each examples of properties that check the width of the rendering surface on the output device. Here's another example with conditional statements applied:

So which mobile email clients support media queries?

Here's what our research showed:

Since Gmail does NOT support embedded CSS, it's really no surprise that media queries are not supported in any of the Gmail mobile apps. The native iPhone and iPad email applications show strong, consistent support for media queries as long as they meet the conditions stated above.

Unfortunately, our testing proved that the native Android email application was buggy to say the very least. At first, it seemed like media queries would render the first time I opened an email but if I re-opened it - POOF!!! - they where no longer supported. Soon after, I came to a point during my testing wherein nothing I tried would work, not even previous tests that passed with flying colors. Before discounting this conundrum entirely, I engaged a few more of our developers and each of them came to the same conclusion. It's not in our nature to give up because it when it comes to computers there's usually a reason for everything but this one had us knocking our heads against the wall.

My conclusion is that media queries are safe to use in email design, especially when optimizing for the iPad or iPhone. As long as your email looks good both ways, you should be good to go!

Devices Tested:
iPhone 4.2.1
iPad 3.2
Android: Sprint HTC Version 2.2

Hotmail does not support the "margin" nor the "margin-top" CSS properties (both inline and embedded) for any HTML element. Our recommendation is to stick with margin-left, margin-right, and margin-bottom properties.

2.) Hotmail's embedded CSS will affect your layout

Hotmail uses the following code in its embedded CSS:

Your email will display within the Hotmail interface so it will take on that style. You can overwrite this in your embedded CSS in order to start with a clean slate for paragraph tags.

For example:

In the above example, I included "margin:0" for all other email clients.

3.) Outlook 2007 and 2010 do not support "padding" in paragraphs

Outlook 2007 and 2010 do not support "padding" CSS property in paragraphs. To get the best results across all clients, we suggest a combination of the two previous suggestions. First, include the above embedded CSS and secondly, stick to margin-left, margin-right, and margin-bottom properties for all paragraphs.

4.) Box model padding issues are back

Box model padding issues rear their ugly head because several email clients strip your DOCTYPE. If that sounded like Latin to you, here's more information: http://www.emailonacid.com/forum/viewthread/47/.

To fix this, never use padding on a box element for which you have already set a width attribute or property. Nesting tables or paragraphs without widths is the best way to go in order to create an email that renders consistently across all email clients. A good way to make sure you are doing this properly is to test in IE7 and Firefox without a DOCTYPE. When you feel good about your final layout, run an Acid Test to preview it in all email clients.

5.) Table element margins and padding in Outlook 2007 and 2010 can cause issues

If you add margin or padding properties to your TABLE element, it will add that same margin and padding to every nested TD in Outlook 2007 and 2010. Cellpadding and cellspacing attributes are safe but it's best to avoid CSS margins and padding within the containing TABLE element.

6.) TD padding is safe but use it with caution

TD padding is generally safe as long as you are not setting a width property or attribute. Outlook 07 and 2010 will convert your width in pixels to points which doesn't always translate as precisely as you may want. If you need to define and control the width of the TD, there are two ways to overcome this issue:

1. You could use a clear gif image (sized to the exact dimensions) within your TD.
2. You could set a width on your containing TD and then use a nested Div, Paragraph, or Table without a width to control the content margins within the TD.

7.) Gmail doesn't support embedded CSS

This, of course makes it difficult to set consistent margins across all browsers. The only obvious fix is to include an inline margin on all paragraphs, ULs, and LIs. For this, you could use our "CSS Conversion" feature which will convert your embedded CSS to inline automatically.

For example, change:

to this:

Also, Thunderbird 2 renders bullets like diamonds rather than circles.

One suggestion to resolve this in every email client is to create a table for every bulleted list and use images or an HTML entity as the bullet itself.

For example:

OR

Doing it this way will also help you to control the bullet point margins and spacing so that it is consistent across all email clients.

This may not be a major issue since its better to use inline CSS wherever possible but we found a work around just in case you have no choice but to use some embedded CSS in your HTML email.

We discovered this solution while testing the @media query support on the Android device. As it turns out - if you wrap a CSS class declaration within a "@media all" block it will render the CSS. Here is an example:

The great thing about this work-around is that the "@media all" CSS block is supported in every email client that currently supports embedded CSS (argh Gmail!). To get the best intended display results, wrap all of your embedded class declarations within a @media query block.

I also tested this fix for linked CSS. Although linked style sheets are not recommended for all email clients, it will work for the native Android email application. All you need to do is include the "media" attribute with a value of "all" like this example:

So from now on remember to wrap all your embedded CSS within a media query block (@media all) and include the "media" attribute in linked CSS tags. That way all of your CSS class declarations will be rendered, barring you don't have any unsupported CSS properties within the declaration.

If you have an align attribute within an image and it is set to "right" or "left" Entourage 04 will add a 3 pixel margin to the left and right of the image. This is especially important if you are trying to get your images to stack up neatly within a table.

To fix the spacing, either remove the alignment or add a CSS margin of "0". For example:

Here is an example of a table with cellpadding and cellspacing set to zero. Each of the images are set to align="right."

Here is that same table with the fix mentioned above.

Note: This issue only effects images, I tested it with DIVs and TABLEs to confirm. I also tested the other values for the align attribute and confirmed that "left" and "right" are the only culprits. This issue only occurs on Entourage 04.

In summary, all email clients ignore the Content-Type defined within your meta tag. Instead, they read it from the Content-Type value that is in the header of your email. The character type value within the header is automatically set by the server sending your email. This value can be changed but you would need direct access to the email server. The safest solution is to convert all of your special characters to HTML entities and we have created a free online tool to help assist you in that process.

What is Content-Type?

A Content-Type tells the web browser or email application how to interpret the text characters in your HTML or the body of the email. The most popular character sets are UTF-8 and ISO-8859-1.

To illustrate, let's take the following code:

Here's how it renders using each character set:

As you can see above, the Chinese symbols are not represented in the ISO-8859-1 character set. This is because ISO-8859-1 only includes Latin based language characters. The result is a bunch of jumbled text, which is the ISO-8859-1 interpretation of the symbols.

Where does this all fit into HTML emails?

In website development, we can tell the web browser what character set to use in a meta tag like this:

Emails are displayed in clients using the same premise. It will display the email based on what Content-Type has been set. However, email clients read the Content-Type value that is set in the email header and they completely ignore the META tag that is within the HTML.

How does the email header Content-Type get set?

The header content is set by the server sending the email and contains information like To, From, Date, Time, etc. Some of which is displayed at the top of each email when viewing it in an email client.

Here is a snippet of an email header (notice the Content-Type value):

Email client test results

I sent the above code example to all the email clients that we support. Pretty much every client renders text based on the Content-Type value set in the email header. Gmail is the only client that automatically converts your text to UTF-8, no matter what the header Content-Type is set to.

Here are the test results:

One thing that I found very suprising is the fact that the web-based clients convert your text to the Content-Type character set prior to displaying it in the browser. I was able to check this by viewing what Content-Type they were setting in their META tags. As it turns out most of them are using UTF-8.

The Solution

Now you might be saying to yourself, great just when I thought designing emails wasn't complicated enough. It does in-fact add another layer of complexity but there are a couple fairly easy solutions.

Option 1:
Contact your email service provider and ask them what Content-Type they set in the header when sending the emails. Once you know the Content-Type use that value in your HTML Meta tag when designing the email.

Option 2:
Convert all special characters to their HTML entities and you won't have to worry about the header Content-Type. For example, the following character "漢" has an HTML entity value of "&#28450;". To help assist you in the conversion we have created a free online tool that will convert all of your special characters for you! Just use this conversion tool before you send your email.

In Conclusion

It is always important to check your character sets using both IE and Firefox, especially if you are using non-Latin characters or copy/pasting content from a text editor like Microsoft Word.

At this time, when you submit an Acid Test, our servers are configured to send your email using the UTF-8 Content-Type to each of our supported email clients.  We will be adding an option for selecting your Content-Type in the near future.

As a follow-up to our recent post: Become a Pro at designing emails on the Android, we mentioned that the Android client increases your font sizes by approximately 110% and that we didn't know of a work-around. Well thanks to Brain Thies and Campaign Monitor, we have a fix you can try out!

Here is an example of a layout rendered in Safari on the PC. As you can see, I am making heavy use of TD padding in order to place text over a background image:

Here is an example of the same layout in the Android (horizontal view):

In an attempt to fix the header fonts and the size of the fonts in my content, I added the following code snippet inside the <head> tags of the email.

Here is how it looked after the fix.

As you can see my fonts are still not matching up exactly. So I decided to dig even further!

Here are the results of a font test I ran comparing the font I used in the above example (Georgia). In my test, Georgia was the only font in the stack. I compared it before and after the fix and in Safari (on my PC):

As you can see, the Android renders the Georgia font differently which is what caused my initial frustration with the above layout. I tested the Georgia font on the Mac and it rendered very similar to my PC. I might consider following up with some further research regarding which fonts come standard on the iPhone and Android OS but from this research, I am currently under the impression that the Android simply doesn't have the Georgia font installed.

In Conclusion

This is certainly a worthy fix and I definitely recommend it for the Android but I would steer clear of attempting to overlay text on images like my example above because it may not be as precise as you'd like it to be. To be safe, make sure that your design is flexible enough to accommodate for a 3% increase or decrease in your font sizing throughout your entire email and use the fix mentioned in this post for optimal results on the Android.

We had a recent question in our forums regarding which clients support hexadecimal vs. RGB values so I figured I would publish the results of my research to our blog as well.

In summary, it is best to avoid using rgb(255,0,0) values when developing HTML emails. Long hex (#F00F00), Short hex (#F00) and colors (red) are supported in all the email clients I tested.

What I found interesting is that some clients support RGB colors on fonts but not in backgrounds or borders. I should point out that I used inline CSS in all of my testing. You can view my test here.

Font Color Test

Border Color Test

Background Color Test

As you can see, my primary focus was on hexadecimal vs. RGB and I used inline CSS. I will research background colors and images - defined by inline CSS vs. HTML attributes in another post.

What I find even more interesting is that the latest DOCTYPE for HTML 5 causes the same image spacing issues! Because of this we might see browsers like Firefox, Safari, Chrome and Opera come out with an update in the near future. Until then, welcome to the party web developers.

The following DOCTYPES cause the spacing:

Examples before any fixes:

Below are some options for correcting the issue.

Option 1.) Add style="display:block" to your image

Example:

This is the most popular fix but as you can see above, it causes a line break before and after your image. If you are working on an HTML email, this fix must be done inline for each image (like the example above) because Gmail does not support embedded or linked style sheets.

Options 2-8.) If your image height is greater than 16px, set the "align" attribute in the image to any of the following: absmiddle, middle, left, right, absbottom, texttop OR top

Example:

Note: align="baseline" and align="bottom" do not work. Keep reading if your image height is less than 16px.

Option 9.) Place the image in a block element with a style="line-height:10px" (or lower)

Example:

Option 10.) Place the image in a block element with a style="font-size:2px" (or lower)

Example:

Obviously, this is only an option if you don't have any text in the container.

Option 11 & 12.) Add style="float:left" OR style="float:right"

Example:

Both Gmail and Hotmail support the float property. Again, if you are working on an HTML email, this fix must be done inline for each image because Gmail does not support embedded or linked style sheets.

If your image is less than 16 pixels high:

Only seven of the above fixes will work:

1. Add style="display:block" to the image
2. Add align="left" to the image
3. Add align="right" to the image
4. Add style="float:left" to the image
5. Add style="float:right" to the image
6. Place the image in a block element with a style="line-height:10px" or equal to the image height
7. Place the image in a block element with a style="font-size:2px" (or lower)

Hopefully at least one of these work-a-rounds will meet your design requirements. If you are aware of additional fixes, don't hesitate to share it below!

Much like it's 'basic HTML' version, images are blocked by default but the option to show images is conveniently located just above the selected email. All of the same rules apply from our original article regarding Alt and Title text while images are blocked.

Thanks to Campaign Monitor for informing us of this revision, our Acid Test results have been updated to reflect these changes.

Since we are in the industry for providing useful developer tools, we've just launched a FREE CSS preview tool. Not only can you preview each style you've created but you can also cut and paste the HTML output so you can use it for future reference.

Here is what has happened to me numerous times in my humble career as a designer. I spend a lot of time creating this perfect style sheet and then six months later my client asks me to revisit the project and I cannot remember what I did in the first place. Of course, if I could only see it, I would immediately recognize it because after all, isn't "seeing" what styles are all about?

After some initial searching on Google, I quickly realized that there wasn't anything available for a down and dirty, oh and did I mention FREE CSS preview so I decided to hunker down and build one myself.

For this first beta release, I created tool that allows users to drop in their CSS and get an instant preview of what each style looks like. Of course it's not every day that you see all of your styles in one, fairly long, scrollable page so I eliminate background images and colors but maintain body or universal (*) styles for all other CSS declairations. I also eliminate any fixed or absolute positioning declarations, so as not to display styles stacked up on top of each other.

Aside from inserting your CSS, you can also provide your web URL - this allows the creation of absolute references for each of your background images. In the result screen you can see the calculated image path based on the first background image referenced in your style sheet. If the path is incorrect, you can adjust your URL accordingly.

Now that so many WYSIWIG editors are smart enough to know what an H1 tag is, you may have clients asking for a CSS "cheat sheet" so that they can use the styles that are available to them. With that in mind, I added an "HTML Output" tab to the results screen. This way, you can easily cut and paste the HTML code which was created by the preview and use it for future reference.

This project is in beta so please report bugs here. If you have comments or suggestions, don't hesitate to share below. Enjoy!

With an ever growing population of iPad users, this creates an interesting challenge for designers - especially when it comes to image heavy emails where the primary message is embedded within a table of sliced images.

So what happens when your images are blocked? The app will only display the ALT or TITLE text in place of your images if you include a width and height attribute or CSS property. If you don't include the image dimensions, it will render as a small, grey outlined box. If you do include them, your ALT or TITLE text will display within a gray outlined box set to the original dimensions of your image. If you have included both ALT and TITLE attributes, it will display the ALT text.

For example:

or

Here is an example of our recent November email campaign:

Most of our messaging is in text but you can see that we did not include a width and height in the image associated with the Android article. Therefore it did not display the TITLE or ALT text description.

In Conclusion

We recommend that you always include an exact width and height for each of your images as well as ALT and TITLE text.

To date, there are two different methods for generating a preview of an HTML email in the most popular email clients. Each solution comes with its own set of challenges and limitations. In this article, we'll watch as the Tortoise and the Hare battle it out to see which strategy wins the race.

Screen Captures

The first approach is to send your email through each email client application and parse together a screen capture of the final result.

Though it may sound like an easy and straight forward task, the Tortoise has some fairly extensive technical challenges. For one, his strategy requires that each of the email clients and mail server ISPs are prompt in processing the original email. It also requires a number of different servers, each processing screen captures for one particular email client. In order to guarantee each email client is up and running, additional servers are required for redundancy.

Using this technique, your email is sent to each individual email client as soon as you submit an email for testing. From there, test results will return in the order that they are received and processed. This allows you to peruse your test results as they become available to you.

Let's take a look at a complete list of pros and cons that may come up with regard to the Tortoise's strategy.

Code Based Previews

The Hare's approach is to generate a preview by analyzing and parsing your original HTML and CSS code much like each of the email clients do. To do this, a proprietary set of diagnostic tests must be sent to each email client to identify how it interprets HTML and CSS. This process must be completed regularly to ensure that web based email client previews are as accurate and up-to-date as possible.

This technique is challenging because there are additional factors involved such as email client style sheets and DOCTYPES. This is very important because your email will be displayed within the layout and style of each web based email client and in a variety of different web browsers and operating systems.

Let's look at the pros and cons the Hare's approach:

Summary

Email on Acid offers both of the technologies listed above and it is our intention to provide code based previews and screen captures for every email client that we support. This gives our users complete control over how they test emails.

We also provide an auto detect feature - if you select this option, we use a combination of screen captures and code-based previews to deliver the fastest, most accurate result based on your web browser and OS.

We have just released beta versions for both the native Android Email Client as well as the Android Gmail Client Application. For those who have not had the privilege to pick up one of these extremely sleek and user friendly devices, let's dive into a few high points with regard to the way they render emails.

The Android essentially resizes each text string so that it fits neatly within the vertical or horizontal viewport. As you zoom in, the text gets larger and wraps nicely so that there is never a need to scroll side to side while reading. This has a fairly drastic effect on your design layout but the payoff is that users will have a much easier time reading the content of your email.  To see the text wrapping for yourself, check out our Android Demo.

Here are a few highlights:

1. The Gmail app does not allow you to zoom whereas the native email client does.
2. Generally speaking, the Gmail app follows the same rules as it's web version counterpart: No support for embedded CSS, and it is better to use the background attribute within TDs vs. relying on backgrounds in CSS.
3. The native email client increases your font size by about 10% - to our knowledge, there is no way of turning the text resizing off.
4. The native email client does not block images and there is no option to do so - whereas the Gmail client does block images by default and there is a fairly large button on the top right for unblocking them.
5. Alt and title tags do not work when images are blocked in the Gmail app.
6. Gmail converts your body to a DIV (in the web version and on the Android Gmail app). This is extremely important because since there usually isn't a width set in your body, the Android sets the width of your converted body tag to that of the device viewport (horizontal or vertical). So if you have a background color or image in the body of your email, it will probably get cut off. Here are a few possible fixes:
   • Wrap the contents of your email in a table or div with the WIDTH set to the widest element in your layout. Attributes or css properties will work. This is a good fix if you do not have a background image in the body tag. If you are using a background color in your body - be sure to add it to your wrapper table or div as well.
   • Add an inline CSS width attribute to your body:
     For example: <body style="width:800px">
     The problem with this solution is that your email will now be left aligned in the web based Gmail client and the background color will not extend to the far left and right. This is because the web based Gmail client will also convert your body to a div. One way to center it would be to add "margin: 0 auto" to the style of your body tag along with the width property.
     
     IMPORTANT NOTE: *You must use ‘px', ‘em', or ‘pt' in either of these options - percentages will not work.
7. The Gmail app does support animated gifs, but animations do not loop. Instead, it stops on the last slide.
8. If there is a height property on a block element that contains text, each client handles it differently. Gmail sets the height of your block element to "auto" so that there is no overlap when the text wraps within it. The native Android client does not wrap text within block elements that have a height property, however it increases the font size so often times there is a text overlap on your box element container. The moral of this story is to avoid height properties on block elements if you want your email to render nicely on the Android.  This does not seem to be a problem from within TDs - just div, p, li, ul, etc. 

Designer Tips and Tricks

All in all, we give this device an A+ for usability, readability, and support for web standards. However, we've seen some layouts get really messed up from the text wrapping. We plan to follow up this blog post with a few more examples but in the meantime, here are some good habits to get into before running your emails through our Acid Test:

1. As mentioned above - wrap the contents of your email in a table or div with the width set to the widest element in your layout. Be sure to include the same background color as you have defined in your body tag.
2. Make sure that your content can wrap freely and avoid adding <br />'s in the middle of sentences.
3. Try to avoid using the CSS height property.
4. Avoid embedding important messages in wide images (over 320 pixels) - users will most likely have to scroll left and right to read it.
5. Text aligned to the center or right will not get wrapped so again, your text might become cumbersome to read in the vertical viewport.
6. If you have text within a TD, be sure the table can stretch vertically without messing up the placement of other images in your table.

This is an email that was sent on October 26, 2010 for Sony Vegas Pro. In this demo, we will show you how the text wraps for easy readability within the email client that comes standard on the Android 2.2.

Here is a preview of how it looks on the Android, as you can see each of the text areas have been resized to fit the viewport so that the user can easily read its content without having to scroll to the left and right.

Although it varries from one device to the next, the standard dimensions for this OS is 320px X 480px. This demo is depicting an HTC EVO^TM from Sprint:

This device does provide a horizontal view as well. If you run an Acid Test you'll be able to preview your email both ways but for this demo, we are only displaying a vertical example. When the phone is shifted horizontally, the dimensions for displaying text change with it. So at a normal zoom the text wrapping starts at 290px (maximum width) in the vertical view and shifts to 450px in the horizontal view.

Also, the native Android email client does allow it's users to zoom in and out. When you zoom in, the text gets larger but is still displayed within the device viewport.

Here you can see which sections of the original design where resized to fit the viewport:

Want to see how your email renders in
Android 2.2 and Android Gmail 2.2?

Step 1:

Test your email in the most popular web browsers: IE 6, IE 7, IE 8, Firefox, Safari, Chrome, and Opera without a DOCTYPE

Step 2:

Run our Acid Test in Firefox or Safari using the following DOCTYPE:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Here's more information about the DOCTYPE and why it is so critical when testing your email designs.

So why is this methodology so important?

Each desktop client uses an embedded rendering engine to display your email. Windows based desktop clients, with the exception of Outlook 2007 and 2010 use the version of IE that is locally installed. Other clients like Thunderbird 2 and 3 use Gecko (Firefox ) whereas Mac Mail and Mac Office 2011 use Webkit (Safari).

If you are on a Mac and you do not have the ability to test in IE, you should test in all the other browsers and then run an Acid Test. In doing so, be sure to select our screen capture options for all Windows based email clients (Windows Mail, Live Mail, Outlook Express, Outlook 2003, Lotus Notes 8 and 8.5). We use IE8 for our screen captures so this will not cover every base listed below but it is better than not testing in IE at all.

Aside from its rendering engine, each desktop client sets specific restrictions on supported HTML, CSS and scripting elements so unfortunately you can't rely on browser testing alone. However, browsers have specific differences in the way they handle tables, block element padding and several other small nuances which you will likely correct in step one.

People use different browsers to view emails in web based clients. Although Firefox and IE are the most popular browsers, people using web based clients can open your email within any browser. When you run an Acid Test, we simulate your email as it would appear in the browser you are using to run a test in. If you already tested your email in each of the most popular browsers, you can save yourself some time and run an Acid Test using Firefox or Safari.

Why Firefox or Safari? Hotmail and Gmail use a DOCTYPE that is only supported in IE. You will pick up on those common issues if you run your Acid test using Firefox (or Safari).

If you skip Step 1, you will never cover all your bases, no matter what testing platform you use. We have recently come out with screen shot counterparts to some of our code based previews. Although there is some debate over which testing method is better and more accurate - if you don't test in all browsers, you will never get the big picture.

For example, we can only provide a screen capture for one possible combination of Outlook 2003:

• Outlook 2003 - with IE 6 installed
• Outlook 2003 - with IE 7 installed
• Outlook 2003 - with IE 8 installed

In our case, we use IE 8 for the screen capture but as many of you know, there are huge differences between IE 6, 7, and 8.

You can cover more email clients and possible client variations in less time. If you follow our methodology for testing, you will correct issues that may arise in each of the email client variations listed below:

Conclusion

We feel very passionate about coming up with a solution to help you test your emails faster and in the least amount of steps possible. With that said, we've recently had some internal discussions about providing screen captures of your email in the most popular web browsers - not in the web-based clients but strictly in the browser itself. This way each of the steps mentioned in our methodology above could be accomplished through our testing platform - all from one browser. It is important to note that this type of feature is something we are considering, actually developing it would be based on user interest.

We are open to comments and feedback!

As if email development wasn't already scary enough, it seems as though we are pushed even further into the HTML and CSS dark ages when it comes to the subject of DOCTYPE. After quite a bit of testing over the past year, we've have come to a very clear understanding of the DOCTYPE, it's effect on your layout and how being aware of it can save a lot of time and frustration.

First, you can't avoid it. Many email clients strip your DOCTYPE and either impose their own or leave it out entirely. Here is a breakdown:

Here are some common things that may happen to your email layout after its DOCTYPE has been stripped:

Since most email clients use a browser based rendering engine or can be viewed from within a web browser, the following list is broken down by occurrences that happen within web browsers.

• Box model padding becomes an issue when viewing your email in IE vs Firefox
• In IE 8, CSS padding on TABLEs are reset to "0" - for example:
  <table style="padding:20px">
• Center tags with a set width will no longer be centered in all browsers except IE. For example: <center width="500px">
• In IE, the minimum height on any EMPTY block element is 19px This is particularly important when using spacer divs.
  <div style="height: 10px "></div>
• In all browsers except for IE 6 and 7, paragraph elements have a default top and bottom margin of "0" whereas it would otherwise use a default top and bottom margin of 16px.
• In IE 8, you might see an exaggerated left margin on OLs and ULs, you will need to define the margins with inline CSS to correct this.
• Some special characters are not supported

Here are some common things that may happen when your email takes on the Hotmail DOCTYPE:

• Line height for small fonts may become more prevalent in all browsers except for IE. This is only an issue when using inline elements, use paragraph elements or TDs for formatting your small fonts.
• You might see a small space below each of your images. A common fix is to use <style="display:block"> inside your image tag.
• Some special characters are not supported
• There may be a difference in the way your text links appear (colored underlines)

If you have more to add to either of these lists, please feel free to share your comments below!

So What's the SOLUTION?

Before running an Acid Test and to save time, we recommend that you strip out your DOCTYPE and test your email layout in IE 6, 7, 8, Firefox, Chrome, Safari and Opera. Once you have it looking good in all browsers, add the Hotmail DOCTYPE and run an Acid test using Firefox or Safari.

By adding a DOCTYPE when you run your Acid Test, we will be able to validate your HTML before you get your test results. We provide code validation for many reasons, the first is to ensure that our test results are accurate. Secondly, your code will be interpreted within the UI of each of the web based email clients - if you have a stray </div>, that could have a big effect on the way your will email render.

IN THIS RELEASE: We've Gone Mobile! New & Improved Code Validation Updated Test Archive & Control Panel Select Specific Clients for Testing Announcing the Final Release of Outlook 2010 Choose from 1, 3, 6, or 12 Month Payment Plans! We've Gone Mobile! Now you can preview your email on the iPhone and BlackBerry devices! Our iPhone simulation has built in features that allow you to slide, scale, rotate, and scroll exactly as seen on the actual device. The interaction is so similar, you might even find yourself reaching up to your monitor to slide it around with your finger tips! Our new Blackberry simulation shows you how your email will look with and without a text alternative. This helps drive home the importance of generating a text version of your email. VIEW A SAMPLE Convert your Embedded CSS to Inline in a Snap Optimizing for Gmail is a breeze with this handy feature! Now you can design your email using embedded styles and then export a fully optimized version with inline styles only. This makes life so much easier, especially for long newsletters and complex email designs! New & Improved Code Validation Catch critical coding errors before they catch you. As an addition to our code analysis features, we now scan your email for critical coding errors before we process your Acid Test. Syntax errors can dramatically affect the way your email renders in each client. For example, if you have a stray </div>, the chances are likely that you will involuntarily interfere with a web based clients' user interface. Coding errors directly affect the accuracy of our test result so if we find anything fishy we report it back to you, from there you can choose to continue with your simulation or you can abort it. Don't worry, we are not as nitpicky as the W3C only the big issues will draw a red flag. Updated Test Archive & Control Panel Subject lines and SPAM results, neatly organized. Now you can enter a subject line for each email so that it is easy to view and compare test results from your archive. We also display your SPAM analysis results for tests that included SPAM reporting. Select Specific Clients for Testing Save time and help us preserve processing power! Now you can select from a list of email clients - this way you don’t have to run a complete test each time. It's a great time saver if you find yourself running the same test over and over to correct issues in a particular client. Announcing the Final Release of Outlook 2010 We've upgraded our Outlook 2010 screen capture servers to Microsoft's production release of their Office 2010 suite. For this client we generate screen captures because simulating the Word rendering engine from Outlook 2007 and 2010 proved to be impossible. We also provide two different code analysis results for Outlook 2007 and 2010. The first is your original code with highlighted discrepancies for what Outlook does not support. The second is Outlook's interpretation of your original code. This is especially helpful for those who are brave enough to reverse engineer its conversion methods. Choose from 1,3,6, or 12 Month Payment Plans Now you can save by purchasing multiple months in advance. Our monthly payment plans include unlimited testing in all of our supported email clients, mobile devices, and SPAM analysis results! *Subscriptions are renewed every term until your plan is canceled. Feel free to visit us online to learn more about our pricing and cancelation policies.

Thank You Message

Thanks to everyone who has continued to support and promote Email on Acid. We are very happy with the feedback that we have received so far and we will to continue to add the features that our members are asking for. If you have any additional requests, please fill out our contact us form.

Cheers and happy testing!

Email on Acid

Email Client Support

Before we ran our test we knew a couple of clients would not display the API fonts. Understandably Gmail would not load the @font-face rule because it doesn't support embedded or linked styles. With the little support that MS Word provides for HTML standards we had a good feeling that Outlook 2007 and Outlook 2010 would not display the Font API. We also knew that the IPhone would not display the custom fonts because Google's Font API does not support SVG - Scalable Vector Graphics. With that said the Font API will also not be displayed on the iPad, iPod, or Andriod devices.

We found it very interesting, however, that there is little or no support for the CSS @font-face rule in most email clients. Only 1 client out of 17 supported Google's Font API. This comes as a surprise to us because most email clients use browser based rendering engines to display HTML email. Due to Apple Mail's HTML/CSS support track record we figured that it would surely support font embedding. Here is the list of clients we tested and their support for @font-face:

Desktop Clients	Result
Apple Mail
Entourage 2008
Entourage 2004
Outlook 2010
Outlook 2007
Outlook 2003
Outlook Express
Live Mail
Windows Mail
Thunderbird 2
Thunderbird 3
Web-based Clients	Result
AOL Web
Gmail
Hotmail
Yahoo (New)
Yahoo (Classic)
Mobile Clients	Result
iPhone

Our Conclusion: Use at your Own Risk

Although Google's Font API is a great resource and can make your job easier when designing web sites we highly recommend against using this API in HTML emails. Based on our test results there is almost no support and the one client that does support it has a very small share of the email client market. However, if you do decide to use this API we strongly suggest using a CSS font stack with the referencing API font.

	Email Inbox - Now you can send a test email directly to your Email on Acid account! From there you have the option to run a free test or purchase credits and preview your email in all 16 of our supported clients!
	Outlook Express - We've added Outlook Express to our list of supported email clients.
	Analysis Summary - Now when you run an email test, we present an overview for how your code stacked up against each email client. Though we still recommend that you preview your email in each client, this analysis summary will show you exactly where problems might be occurring.
	Send your Results to a Friend - Now you can forward your results to a customer or friend for final review and approval.
	Website Translation Tools - Thanks to Google, you can now translate our website into just about any language! This option is now in the footer of every page in our website.

Coming (Very) Soon

Here is a list of features that you can expect to see very soon! Outlook 2010 Beta Spam Analysis & Reporting MobileMe, Excite, MySpace Mail, and Lotus Notes 6,7 and 8! Mobile Device Simulations The Option to Convert Embedded to Inline CSS Link Verification

Thank You Everyone for your Ongoing Support!

Thanks to everyone who has continued to support and promote Email on Acid. We are very happy with the feedback that we have received so far and we will to continue to add the features that our members are asking for. If you have any additional requests, please fill out our contact us form.

Cheers and happy testing!

Email on Acid

In taking into account the complexity of testing your email, we must first consider the most popular email applications used today.

Desktop Email Clients

Each desktop client uses an embedded rendering engine in order to display your email. In order to control potential spam and spyware threats, each client then sets restrictions on supported HTML, CSS and scripting elements. Popular desktop clients include:

	Outlook 2003 IE 6,7 or 8 Engine*		Lotus Notes 6, 7 Rich Text View - similar to Wordpad
	Outlook 2007 Microsoft Word Engine		Lotus Notes 8 IE 6,7 or 8 Engine*
	Mozilla Thunderbird 2.0, 3.0 Firefox Engine		Windows Live (Hotmail) Client IE 6,7 or 8 Engine*
	Apple Mail (aka Mac Mail) Safari Engine		Entourage 2004, 2008 Internet Explorer 5 for the Mac
	Windows Mail IE 6,7 or 8 Engine*

* The version of IE that is used to render your email depends on what the user has installed on their local machine.

Web Based Email Clients

Web based email clients present an entirely different challenge. Since users can open their web based email from any of the popular web browsers, we have to focus less on the embedded "rendering engine" and more on how your email 1.) looks in every popular web browser and 2.) gets interpreted by each email client.

For example: Gmail sets very strict restrictions on embedded CSS, whereas Hotmail uses an outdated doc type which may alter the way your images and text will render.

As if that wasn't enough, your email will render inside the Gmail, Yahoo, and Hotmail user interface.  Therefore, you must compete with their default CSS. AOL, on the other hand, uses an iframe to display your email.

Popular Web Based Email Clients:

The most popular web browsers:

As you already know, each of these web browsers vary when it comes to following W3C standards, rendering coding errors, and displaying blocked images, ALT, and TITLE tags.

Other big contenders include:

• Myspace Mail
• Opera Mail
• Lycos Mail
• Excite Mail

In the end, there are a multitude of different ways in which your email might be received which makes testing much more difficult than testing a standard web page. So the question is:

What is the best strategy for testing your email to ensure it will render correctly in all of the popular email clients?

Here's our recommended approach:

1. Test your email in each of the popular web browsers, including older versions of Internet Explorer. Then, if possible, test on your iPhone or one of the iPhone simulators listed below.
2. Using Firefox, log into your Email on Acid account and run a simulation of your email in the top 15, most popular email clients. Make sure you are satisfied with the way your email will render in each client by using our code analysis feature.
3. Then open Internet Explorer and log into your Email on Acid account once again. Find the email test in your archive and preview the email in each client there as well.

Have you had enough yet? No?
Well, for the hard core testers out there, let's enter into the realm of mobile device email...

Testing HTML Email on Mobile Devices

To make matters even more complicated, some users may use their mobile devices to retrieve their email. Although users are more likely to use the email application that comes with their device operating system, others may prefer to check their web based email through their handheld web browser. There are currently 40 different handheld applications for web browsing.

Here is a list of popular mobile device operating systems:

• Palm OS (aka Garnet or Cobalt) - Made by PalmSource
• Windows Mobile (aka Pocket PC, Pocket PC Phone Edition, and Smartphone) - Made by Microsoft and built on the Windows CE operating system. Applications are Internet Explorer and MS Reader. E-mail program is from the Pocket Outlook Suite and is similar to Outlook (assuming version 03).
• Blackberry OS
  
• Symbian
• Android - Acquired by Google and built on a Linux based platform
• iPhone OS (iOS) - Made by Apple Inc. and built on a Mac OS based platform. The standard web browser is Mobile Safari

Popular Mobile Browsers

• Mobile Safari (comes standard on the iPhone OS)
• Opera Mini (can be installed on any mobile device and there are an estimated 30 million active users)

The good news is that the iPhone has excellent support for HTML/CSS web standards and it is estimated that an average of 2-4% of your potential readers are receiving their email on this device.

Another silver lining to developing emails for mobile devices is that most revert to the attached text version, that is why it is best to embed a link at the header of your text version to a landing page which contains the HTML version of your email. More often than not, that link will launch the standard web browser within the device.

It is our goal to provide simulations for mobile devices in the future. But in the meantime, here are a few online and windows based simulation tools that might help you on your way:

Web Based Mobile Simulators

• dotMobi Online Emulator - mTLD has an online emulator that you can use to quickly see what your site will look like on a common phone
• Opera Mini - a simulation of Opera's popular J2ME browser
• Testiphone - Simulates iPhone browser
• Iphonetester - Also simulates iPhone browser

Windows Based Mobile Emulators

• WinWap Smartphone Emulator
• Microsoft Pocket PC Emulators
• Openwave's Browser Simulator
• Nokia Browser Simulator - this simulator simulates a generic Nokia phone and WAP gateway
• BlackBerry Simulator - multiple different BlackBerry simulators
• Yospace SmartPhone Emulator - a versatile emulator that can display multiple phone instances at the same time
• iPhone Simulator - bundled as part of the iPhone SDK. You'll need to purchase a Mac to run the SDK
• Android Emulator - the Android SDK includes a mobile device emulator. The Android emulator mimics all of the typical hardware and software features of a typical mobile device, except that it can not receive or place actual phone calls
• Palm Pre Emulator - the Mojo SDK from Palm include a Palm Pre Emulator. You can download the SDK for free (requires email registration)
• BREW Emulator - the BREW SDK includes a mobile device emulator. It does not however emulate a handset's hardware. The BREW application is instead compiled to native code and linked with a x86-compatible BREW runtime library.
• MobiOne - iPhone emulator and Palm Pre emulator
• Windows Mobile

We have had a few people ask us how they can use our email testing simulation tool if they do not have access to their URL or HTML code. If you are an email marketer and you are using a third party service or application to create and manage your email campaigns, this article is for you.

Send Your Email Directly - Option 1 (Preferred)

The best way to view your email in all of our supported clients is to send your email directly to your Email on Acid account.

To do that, follow these easy steps:

1. Create an account with Email on Acid.
2. Verify that the body contains your HTML email.
3. Send your email to "username"@emailonacid.com (insert your username and remove the quotes).
4. Log into your Email on Acid account - you will find your inbox in the top right corner of the member Dashboard.
5. From the dropdown, select the "Run a Test" option and you will see the html of your email pre-populated in the content section. 
6. Make your SPAM and Email Client selections and run the test.

It is recommended that you do not forward your email for testing.  Many email applications will re-format your email when you forward it so it is best to send your original email directly from your service provider. If this option is not available to you, feel free to continue reading.

Retrieving HTML Source - Option 2

Most email services like Vertical Response or Constant Contact have a built in feature that allows you to preview your email before you send it. Even if this preview has a header and footer, it is best to copy the source from this location because it is unfiltered. In other words, it hasn't been sent through an email application that may have sifted out or converted the original HTML code.

If your email service provider has a preview capability, follow the steps below:

1. Using IE or Firefox, simply right click anywhere on the preview page (but not over a link or an image) and select "View Page Source" (in Firefox) or "View Source" (in IE)
2. This will open a text file, simply cut and paste all of the HTML code into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Retrieving HTML Source - Option 3

Most email service providers have a "send test email" feature. This would allow you to send a test email to yourself in order to preview it before sending out your final email campaign. When you are ready, send a test email to your personal account then find the email application you are using in the list below and follow the steps to extract the HTML code:

Gmail

1. With Gmail, open the desired message.
2. Click on the down arrow next to "Reply"
3. Now click "Show original"
4. This will open a new window with the source code, cut and paste all of the code into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Hotmail

1. Open Hotmail and check the email in question (don't open the email)
2. Then right click on the message and select "View message source"
3. This will open a new window with the source, cut and paste all of the code into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

AOL (in Firefox)

1. With AOL open and your message selected, right click over your email layout (do not right click when hovering over images or links)
2. In the dropdown choose "This Frame > View Frame Source"
3. This will open a notepad document
4. From there, cut all of the contents from the notepad document and paste it into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Yahoo (in Firefox)

1. With Yahoo open and your message selected, right click over your email layout (do not right click when hovering over images or links)
2. In the dropdown choose "This Frame > View Frame Source"
3. This will open a notepad document
4. From there, cut all of the contents from the notepad document and paste it into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Outlook 03

1. With Outlook03 open and your message selected, right click over your email layout (do not right click when hovering over images or links)
2. In the dropdown choose " View Source"
3. This will open a notepad document
4. From there, cut all of the contents from the notepad document and paste it into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Outlook 07

1. With Outlook07 open and your message selected, right click while hovering over the background of your email
2. In the dropdown choose "view source" - (if you right click over images or text you will not see the option to view source, try making your window larger and right click over the background or below the footer, even if it is white).
3. When you click "view source" - it will open a notepad document
4. From there, cut all of the contents from the notepad document and paste it into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Thunderbird 2.0 and 3.0

1. With Thunderbird open and your message selected, go to "View > Message Source"
2. That will open a text editor with the html source, from there, cut and paste all of the code into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Mac Mail

1. With MacMail open and your message selected, go to "View > Message > Raw Source" from the menu
2. That will change your email to the html source, from there, cut and paste all of the code into the Email on Acid HTML text box and run the test
   

Entourage 04 and 08

1. With Entourage open and your message selected, go to "Message > Source" from the menu
2. From there, cut and paste all of the code into the Email on Acid HTML text box and run the test
   

Windows Live Mail

1. With Windows Live Mail open and your message selected - right click on the message in your inbox and choose "Properties"
2. Then select the "Details" tab
3. Click on "Message Source"
4. This will open a popup window with your source HTML
5. From there, cut and paste all of the code into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Windows Mail

1. With Windows Live Mail open and your message selected - right click on the message in your inbox and choose "Properties"
2. Then select the "Details" tab
3. Click on "Message Source"
4. This will open a popup window with your source HTML
5. From there, cut and paste all of the code into the Email on Acid HTML text box and run the test
   Shortcuts: (In Windows: Control A will select all the copy, Control C will copy the source into your clipboard, select the textbox and Control V will paste contents into the textbox)

Note: Never try to forward your test email for purposes of extracting the source code. Most email applications will reformat your HTML email again when you forward it. Therefore, if you cut and paste code from a forwarded email, you will not get an exact simulation of how your original email would have rendered in each of the popular email clients.

Our API is completely customizable and you can utilize any or all of the features provided. Such features include email previews in any of the email clients and mobile devices that we support, our code analysis, the plain text generator, image blocking, and spam analysis tools.

We currently offer two distinct integration options:

	Reseller Program The first is a reseller program designed to help you generate additional revenue from your current member base. As a reseller, you can mark up our flat rate per scan as much as you want. The flat rate is discounted based on monthly volume. Resellers have the option to private label or, for a discounted rate, they may use the existing Email on Acid brand header and footer.
	Monthly Subscription The second integration option is a monthly subscription allowing for unlimited email tests (or scans). This program is designed to help you provide a value added service to your existing members. Monthly API subscribers pay a royalty fee based on volume of scans per month.

At this time, we are open and flexible regarding our API and would be happy to discuss the best possible integration solution for you. You may even consider using a blend of the two options if it better suites your pricing model.

API Technology

Our application programming interface was built using RESTful Web Services. Therefore, when you send a request to our system, we will return a result in XML format. From a technology standpoint, you have complete control over the way you display, archive, and track each API request. We also provide you with our standard user interface and a framework for the look and feel. However, this is not a requirement - if you want, you can use your own interface design and user interaction tools for displaying email previews and spam analysis reports.

Usage Ideas

Depending on the products and services you offer to your customers, there are many ways you might want to integrate our email preview tools.

Automated Email Service Applications

Your users can preview the way their email will look in the most popular clients within seconds. Our text generation facility can generate a plain text version of each submitted email, you could then allow your customers to edit the text version as they see fit. Some email service providers have also shown interest in our future spam analysis tools, for more information, check out our coming soon section.

Enhance your Corporate Workflow

If you require your customers to provide you with their own custom artwork and html, our test is a great way to help you save time and money. Private label our interface and send it to your clients, this will allow their developers to utilize the code analysis features to lock down their HTML emails before sending you their final artwork. Do what you do best and avoid having to train external developers on the ins and outs of html email design and development.

HTML Email Testing Services and Client Approval

If you currently test your customers' html emails for them, this tool is a great way to save time and money. Avoid having to send a test to 15 different email accounts and 4 different operating systems. With Email on Acid, you can do it all in one place. We also plan on adding a feature that lets you forward the final results to your clients for approval.

Design Templates

If you are currently in the business of selling email design templates, our instant HTML email simulation is a great way to give end users a preview of how each template will look across all the major email applications before making a purchase.

Auto Responders and CRM Applications

Your auto responder or CRM application may have built in features which allow your customers to control the look and feel of their dynamic content emails. You can send your dynamic content through our API for testing and previewing purposes.

Spam Testing & Deliverability Reporting Services

If you provide automated spam testing or deliverability services, you are already providing extremely important email test results to your customers. Why not add a simulation of how their email will render across each of the popular email clients?

Desktop Applications

Last, but not least, you could re-create the functionality of our web-based application as a Windows or OS X desktop application for purposes of reselling to a larger user group.

Email Marketing Web Sites

If you currently have a web site or blog geared toward email marketing, you can use our email preview API to generate revenue from your existing readers. At this time we do not offer an affiliate commission program but we would be happy to entertain the idea upon request.

If you would like to learn more about our API pricing and technical requirements, please fill out this online request form and we will contact you promptly.

After much anticipation, we are proud to announce that our online email testing tool is no longer in Beta! Our new and improved email simulation now includes the following enhancements: Outlook 07 Email Simulation Upgrades - We now provide a rendered screenshot for Outlook 07 along with Microsoft's translation of your original code. Enhanced Image Blocking - Now our test provides an exact simulation for image blocking. Email Test Archive - You can now run a test in Firefox, then login using IE and preview the same test by using our archive feature. G-mail, Yahoo-Classic, and Hotmail Simulation Enhancements - We have included special rules to accommodate for the translation procedures used by G-mail, Yahoo-Classic and Hotmail. Default Style Sheets - We have refined our methods for keeping our default email client style sheets up to date.

Email Testing is now Supported in the Top 5 Web Browsers!

New Pricing Options for Testing your Emails

Unlike all the other email clients, Outlook 07 doesn't just ignore certain elements, properties, and values. Instead, it completely translates your html and CSS into its own, choppy version of your original code. In many cases it translates divs to paragraphs, ULs to a series of spans, and it spits out a whole lot of unnecessary CSS of its own.

For that reason, our code analysis works a little differently for Outlook 07. Instead of displaying your original code, we provide the "translated" version. We then highlight lines of code that are not supported such as floats, forms, and background images.

We invite you to give it a test run, and by all means if you come across a discrepancy please feel free to report it to us. Although we feel as if we have run a million tests by now, Outlook 07 has forced us to completely re-design our database structure and it would really help us to know when and where problems are occurring so that we can continue to make improvements.

Email on Acid Release 1.0 is Coming Soon!

Not only have we improved our Outlook 07 simulation, we have also generated a series of diagnostic tests that we can run through each of our supported email clients to ensure that our test results are on point. As you know, there are thousands of HTML element, property, and value combinations to account for and we sincerely appreciate your patience as we continue to lock down our beta version.

Acid Test Result Discrepancies

The first usage of the term "discrepancy" is designed to identify exactly which lines of code are not supported for each email client.

A discrepancy may or may not alter the final layout in a way that is unpleasing and in many instances, a programmer may use certain CSS properties or HTML attributes that work for a majority of email clients but not for others. In fact, in certain circumstances they are forced to use code that is not supported in all clients just so that their design will render correctly across the board. When certain properties or elements are not "supported" the email client in question simply ignores that code. Therefore, do not confuse the term "discrepancies" with "code errors."

Outlook 07 is the only email client that completely translates your code. This is because Outlook 07 is using a Microsoft Word engine which limits the use of CSS. Therefore, the Email on Acid code analysis result for Outlook 07 is actually their interpretation of the code you submitted.

In summary, if you are satisfied with the way your simulation looks, don't worry too much about reported discrepancies. This feature was designed for HTML/CSS developers so that they can distinguish what works and what doesn't. However, if you do see undesirable spacing or text sizing in the simulation, be sure to bring it up to your designer and/or email service provider.

"Report a Discrepancy" Feature

The second usage for the term "discrepancy" is intended for customer service and support. If you run an acid test and find inconsistencies between our simulation and actual email client results - we want to hear about it!

When you click on this button you are taken to a page where you can share your comments regarding the discrepancy. Please note: there is no need to re-submit your code or URL because we archive the email in question in an effort to make this process easier for our users.

Remember: When using web based email clients (such as Hotmail, AOL, G-Mail, or Yahoo) recipients can receive your email using any of the popular web browsers (IE, Firefox, Opera, Chrome, or Safari). Our acid test is designed to display web email client results as it would appear in the web browser you are running your test in. Therefore if you find a discrepancy in a web based email client, please make sure you are comparing your results in the same browser.

In summary, email application providers are always improving their product so what works today might not work tomorrow and vice versa - especially in web based email clients or in beta desktop clients. We are constantly trying to improve our product and we test email clients regularly for CSS support and compliance, however if you notice inaccurate results, please don't hesitate to use this feature!

We hope this article has helped to clarify these terms, if not, please be sure to give us your feedback.

Using Absolute References (supported)

An Absolute Reference provides the complete http address, the directory path, and the file name. For instance, if you had a file named "logo.gif" in a directory called "images" under the URL "http://www.emailonacid.com" you would link to it as follows:

http://www.emailonacid.com/images/logo.gif

In html context, this might appear as:

<IMG ALIGN=bottom src="http://www.emailonacid.com/images/logo.gif">

Absolute references must also be used inside embedded or inline CSS.

Using Relative References (unsupported)

A Relative Reference provides a partial http address in the form of a fragment of a full directory path. Keep in mind that by default, if no server name or path is specified in html, the file reference defaults to the current directory. If you are publishing files on the web, the default would be any file within your www directory.

To use the example above, you would specify the link as

/images/logo.gif

In html context, this might appear as:

<IMG ALIGN=bottom src="/images/logo.gif">

When we initially started developing our Email Test, our primary goal was to make life easier for the email designers and developers of the world - those who are hired to produce a professional template or layout for their clients. After all, it seems as though making sure the email "looks good" is a responsibility which falls entirely on them and most often their customers assume it's an easy enough task to accomplish.

The fact is, aside from memorizing the web standards chart provided by Campaign Monitor, having 15 email accounts, installing 11 different desktop clients, and managing several machines with different operating systems - ensuring renderability is much easier said than done. We won't even touch the subject of mobile devices and service plans. So why is this subject so rarely talked about? And how many corporate advertisers are being tasked with ensuring the quality of their email campaigns? After all, isn't the corporate identity at stake here?

Even when you run a Google search for "email testing" you will find tons of information on how to test things like target markets, messaging, incentive, subject lines, timing, and destination pages. It's almost as if email marketers are under the assumption that since it looks good in the web browser it will look good everywhere. Unfortunately this assumption couldn't be further from the truth.

In an effort to ensure the quality of our Acid Test result, we ran several high profile corporate email campaigns through the test. We won't name any names because we have no interest in throwing any of those hard working designers under the bus. But we found that 8 out of 10 emails had glitches* and where most likely not tested in most of the popular clients**. This research only goes to show that a majority of custom designed email campaigns are not being tested for renderability.

Maybe its time to spark up a conversation in an attempt to take some of the burden off of the developers themselves...

*unusual spacing between images, unintentional centering, table spacing, missing background colors to replace unsupported background images

** AOL 9, Entourage 2004, Entourage 2008, Gmail, Hotmail, Windows Live Mail, Windows Mail, Mac Mai , Outlook 2003, Outlook 2007, Thunderbird 2, Thunderbird 3 - Beta, Yahoo Classic, Yahoo Mail

We are happy to report that our Email Test has been very well received since going live one month ago! In fact, we are averaging over 100 acid tests per day and we have several members helping us to identify key areas for improvement. Thanks so much for the awesome feedback and we want you to know that we are committed to supporting your requests!

We've also been published on a few French websites! We are thrilled to see that this acid test transcends language and that we are resolving a genuine hardship worldwide. Read more...

As expected, however we have run into a few snags which we are working diligently to resolve. Here are a few articles we've posted identifying some of our trials and tribulations during the month of August:

• Default CSS in Web & Desktop Email Clients
• The Case of a Mystery Escape Character in Hotmail
• Simulating Web Browsers within Browsers
• Simulating Errors in our Email Acid Test
• Outlook 07 Code Analysis Update

We are thrilled to announce that the Email on Acid buzz has begun! In the past week, we have found 7 published articles in various websites detailing current issues regarding the lack of HTML email standards, the challenges of testing, our solution, and a list of the features we offer.

We would like extend our sincere gratitude to those of you who have taken the time to publish us! Here is a list of blog posts we have found so far:

• Ghacks.net: Email Marketing Software Email on Acid
• Efinditnow: Email Marketing Software Email on Acid
• Instant Fundas: Email on Acid: Newsletter Testing and Simulation on Virtual Email Clients
• 1Theme: Email Marketing Software Email on Acid
• Email Marketing Insider: Email Marketing Software On Acid

We've also been published in a few French websites! We are very pleased to see that our acid test and the challenges that it helps to resolve can transcend language. Here are the English translated versions of those articles:

• La Ferme du Web: Email Acid - Testing the integration of emails on different mail clients
• Oxynel, Blog Communication: Top 8: Solutions you need to know!

This much appreciated press goes to show just how tedious it has been for email marketing firms and developers alike to ensure the quality and deliverability of a professional email marketing campaign for their customers. In fact, several professionals have admitted that they don't currently test their email in each of the most popular email clients due to the challenges involved.

We genuinely hope that our product can continue to offer a much simpler approach to testing, resolving issues, and having the peace of mind that your email will render correctly no matter what your readers are viewing it in.

At this time, we would like to re-iterate that we are still thoroughly testing the beta version of our email test. We hope to go live with our first official product release by October 2009. In the meantime, please don't hesitate to point out discrepancies between our test results and actual email client displays as it will only help us to further refine our product for the future.

When we initially built this tool for developers, we decided to include a "Code Analysis" feature which identifies which lines of code are not supported by each email client. This feature is not to be confused with an email validator. A code validator would identify issues with your HTML or CSS such as unfinished or invalid div and table elements.

It is very difficult to "simulate" errors in our acid test exactly the way they might appear in each desktop email client because many of them are using different engines. Each engine has its own rules for handling errors. When running our Email Acid Test, you are using a single web browser with its own rules for rendering errors.

In the future, we may choose include some type of code validation tool so that our Code Analysis not only identifies unsupported CSS but it also highlights errors in your code. However, for the short term, please test your email in the following order:

Step1.) First, test your email in all the popular web browsers (IE 6, 7, 8, FF, Safari, Opera, and Chrome)
Step 2.) Then run your email through our Email Test using Firefox. For even better end results, re-run the Acid Test in IE as well.

Please note: at this time, we cannot be held responsible for discrepancies if your code is invalid. If you find a possible discrepancy, be sure to test your email in various web browsers before submitting a ticket.

As we faced off with the beta version of Email on Acid, we knew some challenges would be harder to deal with than others. The simple fact is that when our users run a test in Firefox (for example) it is difficult for us to perfectly simulate a client like Outlook 03, Windows Live or Windows Mail because each of these examples are using an Internet Explorer engine to render emails. Unfortunately there is no clear solution to this issue aside from simulating some of the more obvious differences.

One obvious difference is the support for certain CSS styles such as the generic "font" property.

Firefox does not support this particular property but IE does. So if a designer where to create their email and only test in IE, their fonts would look exactly as intended. It may also look fine inside the for-mentioned IE desktop clients. But if that developer where to run our email test using Firefox, it wouldn't be an exact simulation - unless we where to add special rules to parse that property so it renders correctly in Firefox.

Other, more complicated issues arise when our users submit code that is full of HTML or CSS errors. As we all know, each of the web browsers have different rules for handling issues like extra table cells and missing close tags. In the end, we may have to implement some type of code validation tool that identifies key issues before running the acid test. For more on that subject - check out our blog post Simulating Errors in our Email Test.

Simulating "Alt" attributes can be another tricky subject. In Firefox, alt text only appears if the image is broken. In IE, the text appears inside a small popup box. Alt attributes are handled differently inside email clients as well - making it difficult to simulate how they would look in any browser. When simulating web clients, it is our goal to render your email exactly how it would look if a user where to be looking at it from within the browser you are running your acid test in. When it comes to desktop clients, we may eventually have to simulate things like alt text and image blocking exactly the way they look inside the client but that will have to wait for a later release.

In conclusion, at this time, we highly recommend you test in this order:

Step1.) First, test your email in all the popular web browsers (IE 6, 7, 8, FF, Safari, Opera, and Chrome)
Step2.) Then run your email through our Email Test using Firefox. For even better end results, re-run the Acid Test in IE as well.

It's official, there's an invisible ghost haunting Hotmail and it had us spooked for over 3 days! OK so we don't mean Friday the 13th scary, but still scary to a programmer who doesn't see it coming!

Turns out it isn't a ghost at all, it's a Microsoft supported escape character which Hotmail adds after every image. As you can rightfully assume, it doesn't lurk in IE but it does in Firefox, Safari, Opera, and Chrome. Since these browsers don't support the escape character, they read it as a special character without any horizontal width (our proverbial sheet over the ghost). That, matched with Hotmail's default CSS (line-height:normal;) creates a vertical space below every image - ah ha - mystery solved!

Whew! Moving on...
Once we figured it out, the next challenge was to simulate the issue in our Email Test. In the end, we are happy to report that we where successfully able to simulate the exact same spacing issues inside FF, Opera and Chrome no matter what size your images are.

This issue of course brings us back to our ongoing question: Should we support multiple web browsers when running our Email Test? So far, the obvious answer seems to be "yes" - considering the fact that results will clearly vary from one browser to the next when it comes to web based email clients. In fact, we feel inclined to simulate your email exactly the way it will look when viewed in the browser you are running your test in.

With all that said; at this time we recommend that you test your HTML/CSS email in the following order:

Step 1.) First, test your email in all the popular web browsers (IE 6, 7, 8, FF, Safari, Opera, and Chrome)
Step 2.) Then run your email through our Acid Test in Firefox for a few reasons...
             a. This will ensure that you see the infamous Hotmail ghost (if it applies to you)
             b. Firefox is the web browser that we have done most of our testing in to date

So what's the solution?

There are several possible work-arounds for this issue, be sure to check out our follow-up post: 12 Fixes for the Image Spacing in HTML Emails

It comes as no surprise that web clients use their own style sheets to render their pages. In the new version of Yahoo Mail and AIM Mail, emails are rendered inside an I-frame allowing for a fairly clean slate. However, in clients like G-Mail, Hotmail and Yahoo-Classic, they seem to make an attempt to reset browser defaults but several of their self-imposing styles are still carried over.

This issue may actually challenge the notion that you are always safe using the basics when it comes to tables and divs. In fact if you didn't know that you needed to overwrite certain styles using embedded or inline CSS, your end result may look much different than expected.

For example, Hotmail applies a margin value to its p, h1-h6, ul, and li elements and ironically they don't support the "margin" property in the rendered email itself. Fortunately they do support "margin-left," "margin-right," and "margin-bottom." In this instance, if you are using a background color or inserting images in any of these elements and you don't set a value for the above properties, you may see unwanted spacing in the end result.

As luck would have it, web clients are not the only ones using default CSS. Most desktop clients use them as well. We hope you can read through our sarcasm here.

Simulating the so called "default" CSS for each email client wasn't a huge problem for us. It was mostly just a matter of being rather tedious and time consuming and as we continue to run test after test, we are sure to refine them as we go.

When we started this Email Test project, we where obviously aware of the current challenges of testing an email in each of the popular clients, but when doing this type of research we find that it may be even more important than we had originally thought. We even ran several high profile corporate emails through our test and saw that default CSS played a big roll in the final output.

That said, we will conclude by repeating the phrase "It's important to beware!"

It doesn't appear that Microsoft is going to play nice with HTML rendering in Office 2010. They are continuing down the '07 path by using Word to render HTML. Are you surprised? Honestly, we aren't.  We have recently received a beta version of Outlook 2010 and through our email tests we have noted the same rendering problems from Outlook 07.

Why are they so stubborn? Microsoft's reasoning behind using Word to render HTML is that emails composed in Outlook 07+ will look consistent when viewed by other Outlook 07+ recipients. They also claim that using the Word engine alows users to easily cut and paste from Microsoft office products directly into their email.  To review a complete online explanation from Microsoft click here.

The problem is that not everyone uses Outlook and to assume that recipients will see an email the way that it is composed in Outlook 07+ is a common mistake. In actuality, Outlook has a very small market share in the ever-expanding world of email clients. To assume that they are the only provider is par for the course for Microsoft, therefore it is not a big surprise that they are headed in the same direction for Outlook 2010.

In the end, in order to create a consistent layout in the most popular email clients, developers will continue to be limited to basic HTML with minimal CSS (in-line or embedded) support. Unfortunately, this has been, and will continue to be extremely frustrating for designers and publishers alike. Not only do they have to use basic html but it limits what they can do in their design especially considering that table background images are not supported.

One would think that if Microsoft where to continue to use the Word engine to display HTML in Outlook that they would fix some of the rendering issues in the Office suite. Unfortunately, from our testing, this doesn't appear to be the case. Either they should revert back to the Outlook 2003 (Internet Explorer) engine for rendering HTML or fix Word so it displays HTML correctly.

As annoying as it is that Microsoft appears to have closed the door on HTML rendering for Outlook 2010, the fight is not over. They are still in beta testing and there is a slight chance that they could change it before the public release. Your voice can be heard. Some nice folks over at fixoutlook.org are in pursuit to influence Microsoft to change Outlook. We invite you to join the cause and let Microsoft read your thoughts.

Needless to say, which ever direction Microsoft decides to go we plan to include Outlook 2010 in our Acid Test result as soon as it is released.  Stay tuned...

Our goal is to help designers understand the do's and dont's for creating a successfull email campaign. This is a community effort to improve the email experience for both designers and readers alike.