One of our customers recently designed a really nice email campaign that had a blue background, with white "title" text on top.
Here’s a snippet of their design in Gmail:
Beautiful.
Even works in Outlook 2007:
But here it is in AOL 9:
Here’s what went wrong…
For the title (MAKEUP LOOK OF THE WEEK!), they used an image
composed of white text, and a transparent background. Besides the
problem of "images turned off by default," this is risky because it
depends on a dark background actually working, and showing through. And
in HTML email, you can’t really depend on anything working properly.
For the blue background, they used a tiling background file.
Background images don’t always work in HTML email. Furthermore, they
specified the background image in their embedded CSS:
#content { background: url("images/email_bg.jpg") bottom left repeat-x; }
Embedded CSS is not very trustworthy anymore, especially in webmail
clients (inline CSS is safest now).
To make matters worse, the url they
used for the background image didn’t use an absolute path, pointing to
the file on their server.
Instead of:
url("images/email_bg.jpg")
It should’ve been:
url("http://www.myserver.com/images/email_bg.jpg")
So even if the embedded CSS worked, the image
still wouldn’t have been downloaded.
Fortunately, they designed the email to degrade gracefully, by assigning a solid blue bgcolor to their table:
<table id="content" bgcolor="#79C0F6" cellpadding="0" cellspacing="0" border="0">
Unfortunately, AOL 9 didn’t accept the blue bgcolor, because the CSS (id=content), with the broken image path, appears to be overriding it.
By the way, same thing broke in Mail.com, Hotmail, Comcast, Outlook
2003, Outlook Express, Yahoo, Thunderbird, and on and on. In fact,
according to their Inbox Inspector report, the blue bgcolor only worked in Gmail, Outlook 2007, and—get this—Lotus Notes.
We re-ran the report after fixing the absolute path, and it rendered properly in all the email programs. If the background-image wasn’t accepted (as with Outlook 2007), the bgcolor was properly swapped out.



Thanks to the person that wrote, “Embedded CSS is not very trustworthy anymore, especially in webmail
clients (inline CSS is safest now).” I needed a good chuckle.
Mail Chimp needs an image gallery seperate from having to upload images through the WYSIWYG editor – so we can manage assets and make the decision ourselves on whether or not we use background images. Sometimes we know quite specifically what our audience is using.
Have you tried using the background attribute on table cells? Seems to work fine for me. Might be worth a look. Seeing as I have to use old / defunct html for emails anyway I had no problem getting dirtier with these deprecated attributes.
Mikey.
Re: separate image gallery — working on that.
But if you know what your audience is using, and you know that background files are safe enough, can you simply use our “upload ZIP” option to send all your files up to MailChimp? We extract the zip, and host all the files for you.
Brilliant Ben! Looking forward to that one.
At the moment I’m hosting my images on Photobucket and using absolute URL’s but it will be nice when I don’t have to use a seperate website for that.
The zip thing was a little confusing as I also (from what I understand) have to upload my HTML with it, but it could change as I refine and test things, so that’s why I didn’t. I could be missing the point completely though.
Thanks for the heads up though!
Mikey.
Here is a link with another solution. More complicated, but I got it to work nicely. Check it out here: http://blog.oxagile.com/2010/04/23/background-images-for-outlook-2007-and-outlook-2010-beta/
Unfortunately, although this method may work for sending the email, MailChimp’s visual editor becomes a nightmare when using a dark image background. The background image ends up covering everything – the drop down menu, the area where text is edited… everything. So, unfortunately, it’s a pretty good method for the real world, but MailChimp’s editing tools need to catch up.
Update -
After tests and trials I figured out that if the background image CSS is input directly on the wrapper table but NOT specified in the styles in the head, the tools will work and the text will be readable.
Hi Ben. The images of this post are broken. :/
Yes they are! Please fix the broken images