Inside the New .Mac Webmail Client

Apple has introduced a new webmail client for their .Mac customers. It’s a truly phenomenal webmail client, functioning nearly parallel to that of their desktop client, Mail. For a brief moment I became disoriented, because while in my browser I was experiencing what I do every day in Mail. Whoa.

GUI.jpg

Of course my first thoughts were concerns for how they may now be handling HTML emails. As I noted in a previous article, .Mac’s previous webmail client had amazing support for CSS and standards-based markup. The two major oddities were easily remedied, and we were on our way.

So how does the new .Mac perform? I ran some tests and the results are in: the plane has crashed into the mountain! (A reference for the Lebowski fans out there.)

Testing: Round One

My first tests lead me to believe that .Mac’s support for CSS completely disappeared. (And that consequently produced a brief daydream wherein I was Tony Soprano chasing down the .Mac developers for some revenge.)

noCSS.jpg

Quickly realizing there were roughly 10,000 lines of AJAX markup (have I mentioned how cool the interface is?) in the .Mac interface, I turned to the amazing Web Developer extension for Firefox to help me locate the markup for my rendered test-message. Once I was in, it didn’t take long to locate the problem.

The new .Mac takes an approach similar to that of Yahoo, whereby a message ID is applied to a new all-encompassing container DIV and every style is prefixed with the respective ID to create child selectors…

Original HTML:
<div id="BodyImposter">
<h1>Headline h1</h1>
<p>Lorem ipsum dolor sit amet…</p>
</div>

Original CSS:
#BodyImposter {
[properties]
}
#BodyImposter h1 {
[properties]
}

Modified HTML:
<div id="messageCanvas_070C9153">
<div id="BodyImposter">
<h1>Headline h1</h1>
<p>Lorem ipsum dolor sit amet…</p>
</div>
</div>

Modified CSS:
#messageCanvas_070C9153 > #BodyImposter {
[properties]
}
#messageCanvas_070C9153 > #BodyImposter h1 {
[properties]
}

This process is obviously aimed at foiling any modifications to the .Mac GUI caused by the use of type selectors. And if properly executed it would not impact the appearance of the source email. However, .Mac adds a gratuitous DIV just inside the new #messageCanvas DIV, consequently rendering all CSS useless…

.Mac-rendered HTML:
<div id="messageCanvas_070C9153">
<div>
<div id="BodyImposter">
<h1>Headline h1</h1>
<p>Lorem ipsum dolor sit amet…</p>
</div>
</div>
</div>

In order for the .Mac styles to work, #messageCanvas_070C9153 > #BodyImposter would need to become #messageCanvas_070C9153 > div > #BodyImposter. Such a seemingly harmless little DIV topples the entire email. The .Mac developers obviously didn’t thoroughly test this process.

Testing: Round Two

I ran a second test to see if I could overcome this problem, but came up short. I added my own child-selector system in the CSS, but did not add it to the HTML…

My HTML:
<div id="BodyImposter">
<h1>Headline h1</h1>
<p>Lorem ipsum dolor sit amet…</p>
</div>

My CSS:
div > #BodyImposter {
[properties]
}
div > #BodyImposter h1 {
[properties]
}

This would account for the gratuitous DIV that .Mac tosses into the mix because I didn’t actually add the new DIV to my HTML. Sure enough it worked like a charm, and .Mac’s support for the CSS in my test email was flawless. But using this process would render the CSS useless in every other email client because the new DIV would only appear in .Mac. Oh, the conundrum.

specialFix.jpg

Grim Conclusion

So the result is that we’re at an impasse with .Mac: either we support other clients or we support .Mac. The former is the obvious choice, leaving us with .Mac emails looking like those rendered in Gmail and Hotmail. Bummer.

I contacted Apple about this bug, but since they do not communicate directly with their customers we can only hope my message is routed/attended to by their .Mac developers. Until then, we just have to live with it. Unless someone out there has a creative solution up their sleeve?

UPDATE: David/Rumble’s recommendation works wonders

I ran a couple tests using this remedy, and all is well with .Mac. The downside is this solution requires a significant increase in markup because every selector must be declared twice. So for anyone considering this technique to preserve formatting in .Mac, I recommend first assessing how many .Mac addresses are on the subscription list.

Posted by Administrator

9 Comments

  • Jeff Adams
    6th December

    That’s a shame, with any luck the Apple folks will get word of this post and remove that silly little div.

  • Rumble
    6th December

    Not sure if this would work, as I don’t have time to test it out at the moment, but you should be able to get around this by doing something like this:

    #BodyImposter,
    div > #BodyImposter {
    [properties]
    }

    Which .Mac would transform in to:

    #messageCanvas_070C9153 > #BodyImposter,
    #messageCanvas_070C9153 > div > #BodyImposter {
    [properties]
    }

    Other browsers would still be able to apply the rule using the child-selector.

  • Jacob Smith
    6th December

    I’ve given up on using any real CSS in emails, it just is too hard to test. I’m back to tables and inline styles.

    I think this the way it is going to be for a while and email designs should conform, just as we don’t design websites with CSS3 in mind.

    The email medium was never intended to be as presentational as clients demand, so we hammer away at a square peg into a round hole. All the while that means we can’t spend as much time on the messaging that is going to determine the success or failure of an email.

  • Kel
    7th December

    Sadly, even Apple’s “own” emails such as receipts from iTunes purchases fail to render properly in .Mac webmail.

  • Ben
    7th December

    I’m far from an expert, but I thought inline CSS solves such problems???

  • Rumble
    7th December

    Mark, thanks, glad this came in useful.

    Ben, inline CSS does indeed get around these problems, but all the same arguments apply as to why not to use inline styles when building webpages: they are repetitive and difficult to maintain, especially if you have complex or long emails.

  • SurveyGizmo
    8th December

    This is so disappointing. The fact that Yahoo or Hotmail is easier to get workable results with than my dear Apple is disheartening. Thanks Campaign Monitor and Rumble for the work in this direction.

  • Daniel Mee
    9th December

    It would seem remarkable that Apple would leave their own emails in such disarray, this would be equivalent to ‘friendly fire’ :)
    However, I was wondering if contacting the relevant itunes bodies and alerting them to the fact (and the solution) would be more effective at “hop[ing] [your] message is routed/attended to by their .Mac developers”. I’m sure the marketing department for itunes australia/america, once informed of the blunder and how sickly their brand looked, would find the correct ‘channels’ to get it fixed! Maybe there are other related companies too like Nextbyte, apple store, quicktime etc that would also have these correct channels.

  • Gerben
    14th December

    Wouldn’t just adding a * in front of every rule solve it.

    so
    #BodyImposter h1{}
    should be
    * #BodyImposter h1{}
    and .mac would turn this into
    #messageCanvas_070C9153 > * #BodyImposter h1

    The * would match the extra div .mac added. On a non-.mac client the * would just match with any element preceding the #BodyImposter, so the rules are still applied.
    The only problem is when .mac fixes this issue.

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

Create an account