Browse by...
Home Resources Blog

Moving past my angst at recent events, I have tested CSS support in two new webmail clients: Yahoo Mail Beta (YMB) and Windows Live Mail (WLM). The results are a nice blend of excellence and incompetence. Surprised? Didn’t think so.

Before I dive in, however, I’d like to preface this article with a particular point of interest. With the release of Outlook 2007 looming it feels oh so very awkward to report on how CSS is handled in other new clients. One might even give in to despair with the realization that irrespective of how a standards-based email renders across the board, it simply won’t fare well in a client used in many offices around the globe.

But from my perspective, it’s clear that we need to overcome this obstacle like other web standards of the past: we push the web community (browser/client developers and web designers alike) to embrace web standards in avoidance of regression. It’s a long road, but well worth the efforts. If we backed down from the parallel challenge with standards support in browsers, today’s web would be a very different place.

I also want to shed some light on the dark caverns of rendered markup in these new webmail clients. There is a current trend in webmail clients which employs a dizzying level of AJAX to make webmail look more like a desktop application. It’s pretty amazing what these developers have accomplished. Anyway, getting to the actual code of a message for viewing rendered markup was quite labor intensive. I owe my gratitude to Chris Pederick who put together the essential Web Developer extension for Firefox which enabled me to get to the source of my test messages.

Yahoo Mail Beta

Yahoo is a company dedicating itself to progress in web standards. I continue to see advances with CSS and accessibility on redesigned pages on their site and within their new products. (Go, Yahoo team, go!) The new YMB client is no exception. My tests revealed a webmail client with serious support for CSS. In fact, it’s the best webmail client I’ve tested. They prove that you can support CSS in a webmail client while maintaining security, speed and top features. Take a peek at its beautiful rendition of my test email:

[screen shot of Yahoo Mail Beta interface]

However, there is one highly unfortunate CSS property that Yahoo still considers to be problematic: position.

In previous articles I outlined how Yahoo Mail replaced all instances of position with xposition, thus rendering them inoperable. Now, however, Yahoo takes this approach to a new level. Instead of making the aforementioned modification, it strips the email of all instances of position. And not just in YMB, but in the original Yahoo Mail as well.

So with Yahoo Mail and YMB, all positioning is out the window. Hello float. All said, I think this is pretty minor in the scheme of things. Thanks, Yahoo.

Yahoo Mail Beta’s score: “excellence.”

Windows Live Mail

Where do I begin? I must give the WLM team credit for their advances in support for CSS, succeeding Hotmail by great strides. Not surprisingly, however, they have failed to offer support for many core CSS properties. In some ways this is worse because Hotmail’s handling of CSS-formatted emails yielded an acceptable email, comparable to a rich-text document. With a half-hearted attempt at CSS support, the result is problematic. Let’s take a look at where WLM falls down.

Margin

Good bye margin. Yep, it’s gone. Every instance. The most significant problems arise when we need to trim default margin to elements like blockquote and need to add to the default margin of elements such as a div:

[screen shot of Windows Live Mail interface]

After WLM eradicates my margin declarations, my blockquote encroaches on the sidebar. And note how all of the text is pushed to the left edge of the window because the margin I applied to my paragraphs and headers has been axed.

Albeit we still have padding, this creates its own complexities when working with even a moderate level of design.

Image Caching

Okay, email service providers, get ready to scream. Ready? When WLM opens an email it grabs linked images and downloads them to a local application-directory. So those tracking images you use to report how many times and email has been opened? You only get one hit irrespective of how many times a message is opened. Okay, let it out. Scream!

This is how it works:

src="https://www.campaignmonitor.com/assets/uploads/logo.gif"

Becomes:

src="https://www.campaignmonitor.com/assets/uploads/logo.gif"

Why does WLM do this? Presumably to cache them for speed. Of course I’m giving them the benefit of the doubt here. (Don’t get comfortable, WLM team—I’m not finished with you.)

Personally, I think it’s a nice uppercut to all of us. But I’ll let you folks decide how detrimental this is to what we do.

Conversion of Quotes

This one is rich. I hope you only want to use fonts with single names such as Helvetica or Georgia. CSS requires that when declaring a value for font-family, two-word names must be enveloped in quotes. So Trebuchet MS must be declared as follows:

font-family: "Trebuchet MS", sans-serif;

WLM says “no” to quotes in values, so the aforementioned sample becomes:

font-family: "Trebuchet MS", sans-serif;

This renders the declaration inoperable, rendering fonts to the browser default. So if our design employs Lucida Grande or Trebuchet MS, per se, we must either accept WLM’s presentation as is and proceed with our two-name fonts or compromise our design with a single-name font.

Background

WLM strips all instances of background. Good bye background images. While this is problematic for our pretty designs, it poses a threat to a more significant issue: accessibility. WLM strips the entire background declaration, which includes any colors therein. So if you have white text atop a colored background, you’re left with invisible content when WLM is finished beating you up.

There is hope, however, in that we can exchange shorthand for longhand when declaring background properties. So:

background: #c1d7ed url("https://www.campaignmonitor.com/assets/uploads/bqTop.gif") no-repeat;

Becomes:

background: url("https://www.campaignmonitor.com/assets/uploads/bqTop.gif") no-repeat;
background-color: #c1d7ed;

This enables us to retain background colors amid WLM’s background-image cleansing. The result, while less than satisfying, is more or less acceptable. Let’s compare.

My test as seen in Yahoo Mail Beta:

[screen shot of background-image success in Yahoo Mail Beta]

The same test as seen in WLM:

[screen shot of background-image failure in Windows Live Mail]

Headers

By default, headers (h1–h6) inherit font properties as previously defined in a style sheet. But with WLM, nothing is inherited. So it is important to redefine font properties as necessary. Fortunately the named value inherit does function within WLM. So font-family: inherit; works as intended. Phew.

ID Replacement

This is by far the worst of the lot, and is reminiscent of the .Mac problem I noted in a previous article.

Webmail clients have evolved to ensure that type selectors do not override CSS declarations for the client itself (a problem for which I have illustrated a considerate solution). The common solution on part of webmail-client developers is to add an all-encompassing div to an HTML email, give it an ID or class, then prefix all class- and id-selectors (from the email) with the ID or class from the new div.

So the CSS/HTML pair:

#Content { }
<div id="Content"></div>

Becomes:

#EC_Content { }
<div id="EC_Content"></div>

A reasonable solution if it were properly implemented. WLM and .Mac both have their faults in that they fail to appropriately match new parent div elements. Where WLM falls down is that it only applies its prefix in the CSS to the first ID/class selector in an element, leaving child ID/class selectors behind.

So the CSS for:

#Content #Primary {}

Becomes:

#EC_Content #Primary {}

But in the HTML:

<div id="Content"><div id="Primary"></div></div>

Becomes:

<div id="EC_Content"><div id="EC_Primary"></div></div>

Obviously this renders all child ID/class selectors inoperable. The good news is that WLM does not prefix type-selectors in either the CSS or the HTML. So:

#Content h1 { }
<div id="Content"><h1></h1></div>

Becomes:

#EC_Content h1 { }
<div id="Content"><h1></h1></div>

I think we dodged a bullet on that one.

Why webmail-client developers can’t get this right is beyond my comprehension. It is vitally important and is an obvious oversight which is now becoming commonplace.

Windows Live Mail’s score: “incompetence.”

In Summary

It comes down to this: Yahoo is leading the way with their support of CSS and web standards, while Microsoft has once again proven they are falling behind. I would gladly stand up and applaud Microsoft for development of a product which offers a high level of support for web standards. But with Windows Live Mail, this is a big “no can do.” As for the Yahoo team, allow me to celebrate your efforts. The first round is on me next time you’re in Portland.

This blog provides general information and discussion about email marketing and related subjects. The content provided in this blog ("Content”), should not be construed as and is not intended to constitute financial, legal or tax advice. You should seek the advice of professionals prior to acting upon any information contained in the Content. All Content is provided strictly “as is” and we make no warranty or representation of any kind regarding the Content.
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

Get started with Campaign Monitor today.

With our powerful yet easy-to-use tools, it's never been easier to make an impact with email marketing.

Try it for free