Straight to your inbox
Get the best email and digital marketing content delivered.
Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.
Subscribe
Even when you’re sending a HTML email to your subscribers, it’s always a good idea to include a text version with the email. There are a few benefits to this approach, which I’ll highlight later, but I recently came across a great case study on MarketingSherpa that highlights another reason to always include a text version. As well as the standard preview pane window, Microsoft Outlook also includes an auto-preview feature that displays the first 3 lines of your email. This gives your recipients a chance to preview your email before deciding to open it. Here’s a screenshot of it in action. By default, the auto-preview will display the first few lines of your text email. If you don’t include a text version however, things can start to get ugly. Instead of seeing a nice intro to your email, your recipient will actually see the first few lines of your HTML version. Outlook still strips your HTML tags, so it’s not all bad, but most HTML newsletters begin with standard content like the name and date of the newsletter or “Having trouble viewing this email” kinds of messages. Not the optimal content to encourage your recipients to open your email. When you send a HTML email with Campaign Monitor and don’t include a text version, we still add a text version for you by default with a small message and a link to view your campaign in their web browser. Again, this works great if someone is having problems viewing your email, but not so hot in Outlook’s auto-preview area. Our recommendation Always include a text version of your email even if you’re only sending in HTML format. Try and provide an enticing summary of the contents of your email in the first sentence or two. This, combined with a good subject and a recognizable from name/address should have a big impact on anyone checking out your email using Outlook’s auto-preview feature. Other reasons to embrace a text alternative On top of the auto-preview benefits, sending both HTML and text in a single email means: Those recipients who have their email environment configured to display text only will still be able to read your email. You’re reducing the chances of your email being filtered as SPAM. Many popular spam filters like SpamAssassin will penalize you for not including a text-version. You’ll even lose points if your text version doesn’t contain similar content to your HTML version. Better formatting when your recipients forward your email. Many popular email environments such as Hotmail will display the HTML version of your message, but when you forward the email it will actually default to the text-version of the campaign instead of garbling the original HTML message. There you have it. A text alternative to your HTML email should increase the chances of your email being delivered AND being opened. Who can argue with that?
I recently helped a customer with a problem that we’ve heard a few times before, so I figured I might post the answer here as well. Here’s the question: “Many of my e-mail addresses have come from a store website (that I will continue to use) that has a simple single opt-in e-mail signup process. As I convert to Campaign Monitor, I want to move to a complete double opt-in process. I would also like to put my current list through a second round of opt-in. Is there a way with Campaign Monitor that I can import a list and then send an e-mail that gives the recipient a link to confirm their subscription to the list as well as unsubscribe if they no longer want to get messages from our store?” First things first, make sure you have permission to contact the recipients in the first place – since this technique is often used on older lists that haven’t been sent to in a while. As we state in our anti-spam policy, permission doesn’t age well and you can’t use Campaign Monitor to email anyone you haven’t contacted in the last 2 years. You’ve got permission, what’s next? Create a new list. From this we can build a link that when clicked, will add the subscriber to this new list. Grab the subscribe form URL, which you can find by going to the ‘Create a subscribe form’ option in your list and locating the URL in the supplied code. This URL will form the base of our link. It should look something like http://clientname.createsend.com/.aspx/s/1234/. Add the recipient’s name and email address to the URL. To do this we add them as parameters to the URL. For the email address, we use the email address field name in the subscribe form code, such as cm-1234-1234. So, the full URL will be: http://clientname.createsend.com/.aspx/s/1234/?cm-1234-1234=[email]&name=[fullname, fallback=""] That’s it, we’re done. By adding that link to your subscription confirmation email, the variables will automatically get replaced with the values in your list that your sending to. Give the recipients a couple of weeks to confirm their subscription, then moving forward you should only send to the new confirmed list. And don’t forget you can test this by previewing your campaign in Step 4.1 when you’re creating a new campaign. Update: A newer version of this process can be found here.
I’ve written a couple articles about using web-standards markup in HTML emails and am even speaking on the topic at an upcoming conference. But one area which I’ve failed to address is image replacement. I have found, read and learned from a handful of good articles/tutorials on the web about this topic. However, I believe they are missing some key components in their construct. And that’s what I will illustrate herein. I approach website markup with a set of techniques which I believe offer the best possible experience for everyone: smart, fundamental markup for those with outdated, graphical browsing devices; appropriate visual-design for those with standards-based, graphical browsing devices; and absolute content accessibility for those with slow connections, non-graphical browsing devices and screen readers. With that said, an area where I admittedly fall down is image replacement. Seeing one’s own design render with CSS on and images off is quite painful when the markup is standards based and all core-design images are CSS backgrounds. Moreover, accessibility is achieved only through a game of hide-and-seek. But there are some magicians from whom we can learn to overcome this. Standing on the Shoulders of Giants Dave Shea posted the most comprehensive study I’ve seen on image replacement. This is where I discovered what I feel is the best technique for preparing HTML markup for the CSS on, images off scenario. His technique sparked the realization that any inline element could be absolute positioned to commandeer the aforementioned scenario. So the techniques I’ll outline herein aren’t a significant evolution of Dave’s technique; they simply buff out a few scratches. They will also exhibit how one might use his image-replacement technique to tightly interweave images with their surrounding elements. With that, let’s look at the techniques I used in an email I recently designed and built for Digital Web Magazine. Image Replacement for Part of a Title Before I construct a website or HTML email I carefully read the content to decide how to semantically mark it up. I consider how it will look and read with no presentation layer. The title of Digital Web’s eNewsletter reads fluently as a single phrase: “Digital Web Magazine Updates Mailing List.” But there is a logo to consider, which is part of that title. I used a single h1 to mark up the title. Then I used a presentation layer to pull out the logo from the rest of the title. The results are as follows: [CSS on, images on] [CSS off, images off] [CSS on, images off] Using Dave’s technique, I created a container for the HTML text (in this case an h1) and added a single, unobtrusive span to house the image and to position it over the text: <h1><a href="http://www.digital-web.com/" title="Digital Web Magazine"><span></span>Digital Web Magazine</a> Updates Mailing List: February 26, 2006</h1> The CSS behind the presentation looks like this: h1 { width: 186px; height: 42px; position: relative; } h1 a { position: relative; width: 186px; height: 42px; } h1 a span { position: absolute; top: 0px; left: 0px; width: 186px; height: 42px; background: url("https://www.campaignmonitor.com/assets/uploads/Logo.gif") no-repeat; } But I needed to position the latter part of the title so that it is not inadvertently masked by the logo. So I increased the total width of the h1, right-aligned the text, positioned the a tag to the left side of the h1 container and left-aligned the HTML text in the a tag which was to be hidden: h1 { width: 540px; height: 42px; text-align: right; position: relative; } h1 a { position: absolute; top: 0px; left: 0px; width: 186px; height: 42px; text-align: left; } All done, right? Almost. Something that Dave’s technique doesn’t account for is increased font sizes. This technique places an image on top of HTML text that’s technically still displayed on the page. So when the font size increases, the HTML text pops out from behind the image. Remember that I was considering a scenario wherein CSS is still on, so I could safely bring down the size of that text so it would be well hidden even with increased font sizes. I also added a little padding to the a tag to increase my breathing room: h1 { width: 540px; height: 42px; text-align: right; font-size: 12px; line-height: 13px; position: relative; } h1 a { position: absolute; top: 0px; left: 0px; width: 186px; height: 42px; padding-top: 23px; text-align: left; } With CSS on and images off the final result was a success, albeit less than satisfying from a visual-design perspective. This is because the hidden HTML text wasn’t formatted with the other content. If I was going to make this work with CSS on and images off, I wanted to go the full nine yards. So I added some color formatting to tie up the loose end: h1 { width: 540px; height: 42px; text-align: right; font-size: 12px; line-height: 13px; color: #999; background: #fff; position: relative; } With that, I had accounted for the presence and absence of graphics and CSS, and also for varying font sizes. Sweet! Relative/Absolute Positioning “What,” you ask, “is relative/absolute positioning?” Oh, it’s something really cool. And I found myself in a scenario that very much warranted use of this technique. I needed to break a single phrase into two lines as such: Powered by Campaign Monitor But I needed to mask the text on the second line with a logo without inadvertently masking the first line: With a simple evolution I could account for varying font sizes, which would otherwise destroy absolute positioning in this scenario. I started with the baseline setup (an h4 container with the extra span tag): <h4 class="Powered">Powered by <a href="https://www.campaignmonitor.com/" title="Campaign Monitor"><span></span>Campaign Monitor</a></h4> But this time I had to consider that the HTML text preceding the image could vary in size. So absolute positioning from the top would fail. Unless I used a relative increment. The following worked out great: h4 { position: relative; } h4 a { position: absolute; top: 1.5em; left: 0px; width: 121px; height: 15px; } h4 a span { position: absolute; top: 0px; left: 0px; width: 121px; height: 15px; background: url("https://www.campaignmonitor.com/assets/uploads/LogoCM.gif") no-repeat; } The key in this technique is the relative value of 1.5em for the top property in the positioning of the a tag. It is absolute positioned, relative to the font size. So the a container (and the image/text therein) will always reside a distance of one half of the height of the em size from the top of the parent container. This accounts for varying font sizes and adds a little padding between the preceding text and the image. Viola. Browser and Email-Client Rendering Aside from Yahoo Mail, most common email clients performed quite well using the aforementioned techniques. And all common web browsers also performed well. Following is a list of browsers and clients used in my tests: Email clients: AOL (webmail) EMail (Zaurus handheld) Eudora 6.2 (OS X, Win/XP) Gmail (webmail) Hotmail (webmail) .Mac (webmail) Mail 2.1 (OS X) Mozilla Thunderbird 1.5 (Linux, OS X, Win/XP) Outlook 2002 (Win/XP) VersaMail (Palm OS) Yahoo Mail (webmail) Web browsers: Blazer (Palm OS) Firefox 1.5 (OS X, Win/XP) IE 5.2 (OS X) IE 5.5/6.0 (Win/XP) Netscape 7.0 (OS X) Netscape 7.1 (Win/XP) OmniWeb 5.1 (OS X) Opera 7.0/8.0 (OS X, Win/XP) Safari 2.0 (OS X) The email clients with solid CSS rendering (Mail, Thunderbird, Outlook, etc.) properly rendered everything with images on and off. Those with poor CSS rendering (Hotmail, Gmail, etc.) displayed the masked text since they don’t display CSS background-images anyway. And the text-only clients successfully displayed the unformatted text. The only problematic email client is Yahoo Mail. This is because (as noted in my previous articles) Yahoo Mail replaces the property position with xposition,” which renders any positioning—and consequently the techniques outlined herein—useless. The good news is that it simply eradicates the images and displays the CSS-formatted text. An acceptable degradation in my book. As for web browsers, those with even moderate CSS support properly render pages using this technique. And those set to not display images see the CSS-formatted text. Awesome. So there it is. I hope my minor evolutions to Dave Shea’s technique help the web community with this less than desirable task. Thanks to Dave and the others from his article for their hard work in building such a solid foundation. This article was authored for Campaign Monitor by Mark Wyner of Mark Wyner Design, a small web design studio in Portland, OR, USA.
If you’ve ever considered adding a little advertising to your email newsletters but never knew where to start? Amigo, a new product from the team at Carson Systems looks really interesting. Here’s the skinny… “The app works like a matching service. If you are an advertiser you can register with Amigo and find hundreds of newsletters in which to advertise your product. If you are a newsletter owner, your small (but targeted) newsletter could be the perfect ad vehicle for one advertiser who is willing to pay a relatively high price per click to reach your subscribers. It’s a match made in heaven!” Amigo is currently in beta, but if you’re interested you can register for their beta program here. We can definitely see this kind of service coming in handy for smaller newsletter publishers looking at generating a little extra revenue.
Campaign Monitor makes it really easy to personalize the subject of your email with your subscriber’s name and email address. The big question is, should you do it? Here’s some nice research from MediaPost’s Melinda Krueger on some recent tests she performed on this very topic. The results were very positive. So positive in fact that every campaign that had a personalized subject achieved a better open rate and often click-though rate. But before you start personalizing every email you send, she also had these important words of advice: “Beware of forcing personalization. Gratuitous personalization can make you sound like a huckster and detract from your message and your brand. Even though these results are pretty impressive, this client did not use personalized subject lines 100 percent of the time.” Let’s also not forget that the option to even consider personalization depends on the quality of your list. There aren’t many bigger email marketing mistakes than to receive a personalized email with someone else’s name. Our recommendation. If you’re confident in the quality of your subscriber name data then try this for your next campaign. See if there was an improvement in your open and click-through rate and make a judgment call yourself.
We’ve published a follow-up post with more recent results – view it here. We recently had a few customers approach us about print stylesheet support and whether or not they can include them in their campaigns. We weren’t sure either, so we did some testing to get to the bottom of it once and for all. What is a print stylesheet? Quick background, print stylesheets basically allow you to set a different set of CSS rules when you print the page to the one you see when viewing it on screen. By specifying a print stylesheet for our newsletters, we could ensure when a subscriber prints our email they see a much more print friendly email that might use simpler formatting and even hide some elements of the email itself. The test Because most email environments won’t let us link to an external CSS file, we used the @media rule to specify our print only styles (more on this here). Here’s a quick sample of the code we used: <STYLE type="text/css"> @media print { p.printme { font-size: 10px; color: #f00; } } @media screen { p.printme { font-size: 40px; color: #000} } </STYLE> The results Email client @media print { … } media=”print” Apple Mail 4 Yes Yes Outlook Express/2003 Yes Yes Outlook 2007/2010 No No Thunderbird Yes Yes Yahoo! Mail No Yes Gmail No No Windows Live Hotmail Yes No As you can see, the results were quite varied. None of the web-based email environments supported the print-friendly version, but most of the desktop environments did. Ultimately, we can put this down to lack of support for the @media rule. Unfortunately, since none of the web-based environments support the use of the link element for embedding external stylesheets, the @media rule is the only option available. Conclusion From our quick tests it appears that including print styles via the @media rule doesn’t do any harm in email environments that don’t support it (as they are ignored completely). If you’re sending an email like an invitation with specific details or any other kind of email your recipients are likely to print, you may want to consider adding a few print specific styles if it will make your email easier to read. If any of you guys have had other experiences with print stylesheets and have anything to share, I’d love to hear it.
I recently put together an article on email design for the awesome web design resource Vitamin. This was a combination of ideas I’ve covered in previous articles in this blog and some new recommendations to boot. Check it out and while you’re at it be sure to take a peek at the top notch content on the rest of the site.
Yesterday we finally moved our payment system over to a US based provider, doing away with messy currency conversions and that word that scares book keepers worldwide – “approximately”. Unfortunately our merchant provider is having problems processing payments for our American Express customers. They’ve promised us the situation will be resolved within 24 hours (by 6pm CDT on Tuesday) – and we’ll post an update here as soon as that’s the case. Update: The problem has now been resolved, so our Amex customers will have no problems sending campaigns or buying credits. Thanks so much for your patience and understanding throughout this issue. Now, I need a beer.
We’re always pretty happy when we push a new update live or make improvements to Campaign Monitor, but nothing’s more flattering than when a customer does all the hard work for us. Jordan Brock of Australian based Spin Technologies has just announced the release of an open source Ruby on Rails wrapper class for the Campaign Monitor API. If you’re developing in Rails, this makes it a piece of cake to interface with our API from your own applications. They’ve set up a RubyForge project with documentation, as well as a trac install for bug tracking and to browse the source. A huge thanks to Jordan and his team for getting this project off the ground. We’ve also got some significant updates planned for the API real soon.
Update: This study has since been superceded by the new and improved 2008 Edition Since the rise of Internet Explorer, web designers have had to test their designs across multiple web browsers. No one likes it, but we’ve all copped it on the chin, written a few hacks and moved on with our lives. After all, 3 to 4 browsers aint that bad – and they finally seem to be getting their act together. If Internet Explorer is the schoolyard bully making our web design lives a little harder, then Hotmail, Lotus Notes and Eudora are serial killers making our email design lives hell. Yes, it’s really that bad. Inspired by the fantastic work of Xavier Frenette, we decided to put each of the popular email environments to the test and finalize once and for all what CSS is and isn’t supported out there. We’ll dig straight into our recommendations based on what we found, followed by the results themselves with a few more details about our findings. Recommendations Because of the huge variation of support across each email environment, there really isn’t any one design approach that will guarantee consistency. Instead, you should take a couple of things into account. 1. The consistency demands of your client If you have a client who understands the challenges you face and realizes that some email environments are just plain old broken (we can always dream), I recommend going for broke and following Mark Wyner’s recent article on CSS design in email (we even include a free template to get you started). This allows you to code your email using moderns standards based design that degrades gracefully for these “broken” email environments. On the other hand if your client demands consistency no matter what, or the CEO’s using Lotus Notes, you’ll have to dull down your design, stick with tables for layout and use only basic text formatting via CSS. You may even have to go down the inline CSS route. 2. The potential email environment of your recipients You’ll probably need to generalize a little here, because most of us have no idea what email environment each recipient is using. Business to Business If you’re sending Business to Business (B2B) emails, you’re definitely going to have to support Outlook and to a lesser extent Lotus Notes. In a recent survey of B2B readers, EmailLabs found that more than 75% use a version of Outlook and a further 9% use Lotus Notes. The good news is that Outlook’s support for CSS is quite good, but Notes’ certainly isn’t. You’ll need to weigh up the trade-offs yourself there. Business to Consumer If you’re sending Business to Consumer (B2C) campaigns, then you’ll definitely need to have Yahoo!, Hotmail and possibly AOL covered. Gmail’s still purring under 5% total penetration, but if you’re targeting early adopters then this percentage will likely be significantly higher. Yahoo and AOL offer very respectable CSS support. Hotmail isn’t too painful provided you include your <style> element in the <body> and not the <head>, while Gmail gives you no choice but to use inline styles only. Further to these concerns, there’s also the issue of image blocking and preview panes, but that’s a whole other article. Results Down to the nitty gritty. To cover each email environment, we’ve split our results up into web-based, PC and Mac email software. Use the links below to jump straight to the respective findings. Web-based results – Gmail, Hotmail, Yahoo! and Windows Live Mail PC results – Outlook 2003 and Outlook Express, Lotus Notes, Thunderbird Mac results – Mac Mail, Entourage, Eudora Web-based Xavier covered the web-based email environments perfectly, but we decided to throw Microsoft’s new Windows Live Mail into the mix to gaze into the crystal ball and see if Hotmail may have a brighter future. The biggest improvement we found being support for the <style> element in the <head> of your page. The <style> element The standard place for the style element is in the <head> of the document, but to ensure the styles appear in Hotmail, you can also insert them within the <body>. We tested both, just to make sure. Web-based support for the <style> element Gmail Hotmail Yahoo! Mail Windows Live Mail <style> element in the <head> No No Yes Yes <style> element in the <body> No Yes Yes Yes The <link> element The <link> element is used to reference a separate CSS file. Web based email environments offer no support for this element, so I recommend playing it safe and sticking with the <style> element for your CSS. Web-based support for the <link> element Gmail Hotmail Yahoo! Mail Windows Live Mail <link> element in the <head> No No No No <link> element in the <body> No No No No CSS Selectors Selectors are used to “select” specific elements on a page so that they can be styled. Besides Gmail, most web-based email environments offer pretty good selector support. Web-based support for CSS Selectors Gmail Hotmail Yahoo! Mail Windows Live Mail * No Yes Yes Yes e No Yes Yes Yes e > f No No Yes No e:link No Yes Yes Yes e:active, e:hover No Yes Yes Yes e:focus No No Yes No e+f No Yes Yes No e[foo] No Yes Yes No e.className No Yes Yes Yes e#id No Yes Yes Yes e:first-line No Yes Yes Yes e:first-letter No Yes Yes Yes CSS Properties CSS property support ranges from very good (Yahoo!) down to so-so (Gmail). If you want results in Gmail, you’ll need to do your styles inline (<p style="...">this is pretty now</p>) rather than via the <style> element. Web-based support for CSS Properties Gmail Hotmail Yahoo! Mail Windows Live Mail background-color Yes Yes Yes Yes background-image No Yes Yes No background-position No No No No background-repeat No Yes Yes No border Yes Yes Yes Yes border-collapse Yes Yes Yes Yes border-spacing Yes No Yes No bottom No Yes Yes No caption-side Yes No Yes No clear No Yes Yes Yes clip No Yes Yes No color Yes Yes Yes Yes cursor No Yes Yes Yes direction Yes Yes Yes Yes display No Yes Yes Yes empty-cells Yes No Yes No filter No No Yes Yes float No Yes Yes Yes font-family No Yes Yes Yes font-size Yes Yes Yes Yes font-style Yes Yes Yes Yes font-variant Yes Yes Yes Yes font-weight Yes Yes Yes Yes height No Yes Yes Yes left No Yes Yes No letter-spacing Yes Yes Yes Yes line-height Yes Yes Yes Yes list-style-image No Yes Yes No list-style-position Yes No No Yes list-style-type Yes No Yes Yes margin Yes No Yes No opacity No No Yes Yes overflow Yes Yes Yes Yes padding Yes Yes Yes Yes position No No No No right No Yes Yes No table-layout Yes Yes Yes Yes text-align Yes Yes Yes Yes text-decoration Yes Yes Yes Yes text-indent Yes Yes Yes Yes text-transform Yes Yes Yes Yes top No Yes Yes No vertical-align Yes Yes Yes Yes visibility No Yes Yes Yes white-space Yes Yes Yes No width Yes Yes Yes Yes word-spacing Yes Yes Yes Yes z-index No Yes Yes No PC Aside from Lotus Notes, all our PC-based email clients behaved very well. All versions of Outlook, Outlook Express and AOL 9 use Internet Explorer to render their emails, so some selectors weren’t supported. This also means you’ll still need to allow for the range of CSS problems IE introduces. Thunderbird scored beautifully. The <style> element Perfect support except for Lotus Notes, which ignores the <style> element altogether. PC support for the <style> element Outlook 2003/OE AOL 9 Lotus Notes Thunderbird <style> element in the <head> Yes Yes No Yes <style> element in the <body> Yes Yes No Yes The <link> element The <link> element is very well supported on the PC, the only shortfall being that your remote CSS file will not be loaded if images are also disabled. Once images are enabled, your CSS will also load correctly. PC support for the <link> element Outlook 2003/OE AOL 9 Lotus Notes Thunderbird <link> element in the <head> Yes Yes Yes Yes <link> element in the <body> Yes Yes Yes Yes CSS Selectors Thunderbird scored highly, but because the majority use IE to render your email, selector support is limited. PC support for CSS Selectors Outlook 2003/OE AOL 9 Lotus Notes Thunderbird * Yes Yes No Yes e Yes Yes No Yes e > f No No No Yes e:link Yes Yes No Yes e:active, e:hover Yes Yes No Yes e:focus No No No Yes e+f No No No Yes e[foo] No No No Yes e.className Yes Yes No Yes e#id Yes Yes No Yes e:first-line Yes Yes No Yes e:first-letter Yes Yes No Yes CSS Properties You can have a field day as long as you’re not sending to Notes. It offers dismal property support that includes only very basic text manipulation. PC support for CSS Properties Outlook 2003/OE AOL 9 Lotus Notes Thunderbird background-color Yes Yes No Yes background-image Yes Yes No Yes background-position Yes Yes No Yes background-repeat Yes Yes No Yes border Yes Yes No Yes border-collapse Yes Yes No Yes border-spacing No No No Yes bottom Yes Yes No Yes caption-side No No No Yes clear Yes Yes No Yes clip Yes Yes No Yes color Yes Yes Yes Yes cursor Yes Yes No Yes direction Yes Yes Yes Yes display Yes Yes Yes Yes empty-cells No No No Yes filter No No No No float Yes Yes No Yes font-family Yes Yes Yes Yes font-size Yes Yes Yes Yes font-style Yes Yes Yes Yes font-variant Yes Yes No Yes font-weight Yes Yes Yes Yes height Yes Yes No Yes left Yes Yes No Yes letter-spacing Yes Yes No Yes line-height Yes Yes No Yes list-style-image Yes Yes No Yes list-style-position Yes Yes No Yes list-style-type Yes Yes Yes Yes margin Yes Yes No Yes opacity No No No Yes overflow Yes Yes No Yes padding Yes Yes No Yes position Yes Yes No Yes right Yes Yes No Yes table-layout Yes Yes No Yes text-align Yes Yes Yes Yes text-decoration Yes Yes Yes Yes text-indent Yes Yes No Yes text-transform Yes Yes No Yes top Yes Yes No Yes vertical-align Yes Yes No Yes visibility Yes Yes No Yes white-space No No No Yes width Yes Yes No Yes word-spacing Yes Yes No Yes z-index Yes Yes No Yes Mac While Mac Mail and Entourage offer fantastic support across the board, I wasn’t surprised to find that Eudora refused to come to the party. Basically, Eudora sucks. The <style> element Go for it, just ignore Eudora. Mac support for the <style> element Mac Mail Entourage Eudora <style> element in the <head> Yes Yes No <style> element in the <body> Yes Yes No The <link> element Same old story, no Eudora. Mac support for the <link> element Mac Mail Entourage Eudora <link> element in the <head> Yes Yes No <link> element in the <body> Yes Yes No CSS Selectors Mac Mail support was fantastic and Entourage was a close second. Mac support for CSS Selectors Mac Mail Entourage Eudora * Yes Yes No e Yes Yes No e > f Yes Yes No e:link Yes Yes No e:active, e:hover Yes Yes No e:focus Yes Yes No e+f Yes No No e[foo] Yes No No e.className Yes Yes No e#id Yes Yes No e:first-line Yes Yes No e:first-letter Yes Yes No CSS Properties Property support was also top notch, except for Eudora, with no property support whatsoever. Mac support for CSS Properties Mac Mail Entourage Eudora background-color Yes Yes No background-image Yes Yes No background-position Yes Yes No background-repeat Yes Yes No border Yes Yes No border-collapse Yes No No border-spacing Yes No No bottom Yes Yes No caption-side No No No clear Yes Yes No clip Yes Yes No color Yes Yes No cursor Yes No No direction Yes No No display Yes Yes No empty-cells Yes No No filter No No No float Yes Yes No font-family Yes Yes No font-size Yes Yes No font-style Yes Yes No font-variant Yes Yes No font-weight Yes Yes No height Yes Yes No left Yes Yes No letter-spacing Yes Yes No line-height Yes Yes No list-style-image Yes Yes No list-style-position Yes Yes No list-style-type Yes Yes No margin Yes Yes No opacity Yes No No overflow Yes No No padding Yes Yes No position Yes Yes No right Yes Yes No table-layout Yes Yes No text-align Yes Yes No text-decoration Yes Yes No text-indent Yes Yes No text-transform Yes Yes No top Yes Yes No vertical-align Yes Yes No visibility Yes Yes No white-space Yes Yes No width Yes Yes No word-spacing Yes Yes No z-index Yes Yes No We hope you find these results helpful. Let’s hope that as browsers move forward, ISP’s and email client developers follow suit. It’s our sanity at stake here, right? UPDATE: After an oversight pointed out by Lachlan Hunt, we’ve scaled back Eudora’s CSS support to nil, zilch, zero.
One of our customers recently spotted a strange and very annoying Hotmail bug that modifies the appearance of your email. If you include the word News in your campaign followed by a colon, so News:, Hotmail will automatically convert this into the following JavaScript link. javascript:ol('News'); When you think about it, this term can easily appear in tonnes of emails. Can anyone say Latest News:? The worst part is, clicking it will take you to a Hotmail 404 error page. We assume Hotmail is doing some kind of conversion thinking this is the news: protocol for newsgroups, but this doesn’t seem to actually work anyway. We’ve been in touch with Hotmail about his issue, so hopefully it’s something they resolve soon, but in the mean time, avoid using News: anywhere in your email content if you’re sending to Hotmail recipients.
Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.
SubscribeFrom Australia to Zimbabwe, and everywhere in between, companies count on Campaign Monitor for email campaigns that boost the bottom line.
Get started for free