How Windows Live Mail and Yahoo Mail Beta Shake Out with CSS

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="/your/path/logo.gif"

Becomes:

src="ApplicationMain_11_data/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("img/bqTop.gif") no-repeat;

Becomes:

background: url("img/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.

Posted by Administrator

28 Comments

  • Brent Spore
    25th January

    My continued applause for being on top of things for us out here. Microsoft does it again. Does anyone remember the old “Microshaft” website? It’s all coming back to me now. Will this ever end?

  • Ryan Kennedy
    26th January

    Mark, thanks for the incredibly thorough investigation and writeup. We’ve worked really hard on Yahoo! Mail and Yahoo! Mail Beta to make sure that we do the best job possible of making reading your mail a very safe experience while at the same time not degrading the quality of the messages you receive.

    Regarding the position property, I’ll drop a line to the appropriate people to see if there’s any particular reason we don’t trust it.

    Ryan Kennedy
    Yahoo! Mail

  • James Walker
    26th January

    Wow - now that’s what I like to see - Yahoo! are obviously on the ball on this one and engaging with people like us out there - good stuff guys!

  • Joseph
    26th January

    Don’t forget the center issue: If you have align=“center” on a table, EVERYTHING in the table gets center aligned. All of your text, etc….center aligned. So you have then put align=“left” on every td in your nested tables.

  • Ryan Kennedy
    26th January

    I’ve been talking with some folks here about the position issue. Here’s the main problem…since we take the HTML from the message and put it into the HTML of our application, there’s a possibility that evil-doers might use the position property to move components of their message out of the message reading area and into our webmail UI.

    That might seem like it would be a minor annoyance, but imagine a mail message that contains something that looks an awful lot like part of our UI. They could use CSS positioning to move that over our UI and the user likely wouldn’t even notice. That opens the door for phishing, which we’re very sensitive to.

    That’s the main issue. We’re still talking about it, seeing if there’s anything we can do, but it’s a difficult problem to solve. Hopefully that gives you some idea why we don’t allow CSS positioning right now.

    Ryan Kennedy
    Yahoo! Mail

  • Simon Kitson
    29th January

    Well, that certainly is a good reason for stripping the position property Ryan and one I’m sure many of us had not considered. I suppose we’re all too nice to think like that…

    Another punch in the gut from Microsoft then. They really must hate us.

  • Ryan Kennedy
    29th January

    Well, cut them a little bit of slack. It’s not an easy problem to solve. It’s also worse for the image of the product to allow a phishing or cross site scripting attack than it is to mess with HTML design. That’s not an excuse, just an indication of where priorities may lie.

    Fortunately, at Yahoo! we have some really smart people working on this problem and they were able to strike a fantastic balance of making HTML mail safe to read while at the same time not mangling it so horribly that it doesn’t make sense anymore.

    Ryan Kennedy
    Yahoo! Mail

  • Simon Kitson
    30th January

    Whilst I have every sympathy for the team at Live Mail (security obviously has to be their first priority), the constraints within which they must work are endemic of a corporation that appears to have a total disregard for the web design community. Perhaps I am being too harsh, but with the exception of IE7, Microsoft has not exactly endeared itself in that respect for some time now.

    What yourself and the team at Yahoo! have produced is a model of what can be accomplished and you should be applauded for it. I sincerely hope Yahoo! Mail enjoys the success it clearly deserves.

  • Ryan Kennedy
    30th January

    Mark, the issue with your constraints (child and positive offsets) doesn’t fulfill everything. Imagine setting a positive “right:” value. Set it big enough and you flow back out into the folder navigation on the left side.

    On the flip side, set a big enough positive “left:” and now you’re out in our ad space on the right hand side. It’s not enough to check that the values are positive, we have to check to make sure they’re not so large that they flow out of their container, which is tricky at best.

    Ryan Kennedy
    Yahoo! Mail

  • Ryan Kennedy
    2nd February

    If anything is appreciated, it’s the effort you put into your “Pepsi challenge” of CSS handling. ;)

    Ryan Kennedy
    Yahoo! Mail

  • anonymous
    3rd February

    Anyone else having any issue with Yahoo and Firefox with RT and HTML emails?

  • Derek A
    8th February

    > 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.

    What’s the secret?

  • Kevin
    10th February

    With respect to the Microsoft WLM image caching, doesn’t it seem like the end goal here would be to cache all images for a given commercial email blast in one place and source them locally? 

    I assume the same types of Bayesian-ish systems that detect repetitive patterns in email source and email content (at the service provider level) already learn to group like emails from a given source based on their content.  In that case, it seems like it would be a no brainer to notice that the service just got 200,000 commercial emails with the same content and point their images all to the same place (since they’re already altering the markup in the email to do that).  Right now the image blocking is annoying for users as well as email marketers and single-sourcing the images would seem to be a good compromise (from the webmail provider’s point of view) in allowing the image to be seen without providing what they consider to be compromising data.

    Again, I’ve always been on the outside looking in, but from patterns I’ve observed from the outside it seems like the technology used to monitor UCE already performs the key functionality that you’d need.

  • Ian
    16th February

    HELP….
    What is wrong with MSN LIVE MAIL!?!?!?

    Sending this to msn live messenger, and the image has a 1px broder at the bottom…..i have tried everything…....cananyone help?


     
     
     
     

      hello


    Ive scoured the web to no avail of any solutions to this…..why does webmail render images wrongly (add padding, when they are within a td????

    any ideas welcome….

    Ian

  • guest
    17th March

    In windows live mail why is there black lines showing on images when I Scroll down!?! how can this be fixed??


  • 16th May

    i get the same lines! its very annoying! can anyone help???

  • JB Hurteaux
    22nd June

    Hello,

    Is it just me or is margin-bottom working on Live Mail?

    regards,
    JB

  • Robert Sedor
    3rd July

    Outlook 2007 doesn’t support padding properly, so I switched my designs to use margin.  Now Hotmail doesn’t support margin at all.  Another Microsoft Hobson’s Choice.  Do they have it in for HTML email coders ;(

  • Steve Cartoon
    14th July

    OK, as far as the 1-pixel border at the bottom of images, this is a Murkysoft bug dating from WAAAY back (IE 4.0, I think). The solution is to put your closing </td> RIGHT AFTER your image declaration. Give that a go…

    And yes, I think Murkysoft DOES have it in for us coders. Do you know that the humble <p> tag is not supported in Windoze Live Mail? And I always wondered why support for the onClick event handler doesn’t exist in IE, even in IE 7.0…

     

    But that’s not all! Add that to <div> being removed and <style> blocks completely removed (whether or not the style declaration block was in the <body>) from Gmail, and we find ourselves going forward into the past to properly compose HTML-based e-mails.

     

    So, although it really rankles to be coding circa 1999, <table> (max 600 px), <font > (yes, this apparently works across the board), and inline styles circa CSS 1.0 seem to be really all you can use…

     

    From what I’ve seen, margin is not supported by Windoze Live Mail, AOL, and Hotmail. So if margin-bottom appears to be working, bet that’s a bug…like that’d be anything new…so I guess you might be stuck using the old 1x1 transparent pixel stretch to get your margin. Probably inside a table cell to ensure some rigidity…

     

    Good luck! (We’re gonna need it…)

  • Steve Cartoon
    14th July

    Okay, looks like some characters didn’t show up there…

    First p: ...put your closing td tag RIGHT AFTER…
    Second p: ...the humble p tag…
    Third p: Add that to div being removed and style blocks completely removed…
    Fourth p: ...coding circa 1999, table (max 600px), font (yes, this apparently…

    Sorry about that!

  • Dave Greiner
    14th July

    Steve, thanks for the great comments and sorry about the tag support there. I just jumped in and fixed up your original comment, and will look into making some tweaks to the blog to better support them from now on.

  • Kinger
    18th July

    Also, after sweating for while about this, as well as the Microsoft 1 pixel gap bug, I also realised that Window Live Mail appears to be the only Webmail Client that renders in in standards mode, so any inline element in a table cell (img is an inline element by default) will be aligned to the text baseline - that allows space for the descenders that extend below the baseline on some letters. That’s why there appears to be an unwanted gap beneath the img and the table when using Windows Live Mail and Firefox. The solution is to add style=“display:block;” to images.

  • Justine
    31st October

    Kinger,

    Have you noticed any ill effects from adding style=“display: block;” to the images in any other email clients? We’re doing some testing over here…

  • Matt
    1st November

    Kinger/Justine,

    I was thrilled to find that your style=“display:block;” fixed the problem in Live Hotmail, BUT then discovered this code COMPLETELY BREAKS the display of the email in Entourage for the mac. When I saw “completely” I mean that the email is almost totally unreadable. All of the images that use “display:block” seem to be stacked on top of each other… almost like they are on different layers.

    This might be exposing a bug in Entourage, but is there any other possible fix for the bottom padding in Live Hotmail?

  • Toucouleur
    22nd November

    I have been working on this issue for a while… thanks a lot for the tip regarding style=“display: block;”

    Thanks again, you helped me to keep stupid hotmail customers users ;)

  • Gary Levitt
    12th March

    Solution:

    margin-top: x;
    margin-right: x;
    margin-bottom: x;
    margin-left: x;

    True, Hotmail strips margins, but not when they’re absolutely specified.

  • Dik
    3rd June

    Outlook 2007 doesn’t support padding properly, so I switched my designs to use margin.

  • Rules
    26th August

    Here’s the main problem…since we take the HTML from the message and put it into the HTML of our application, there’s a possibility that evil-doers might use the position property to move components of their message out of the message reading area and into our webmail UI.

Sign up for free.
Then send campaigns for as little as $9/month

Create an account