CSS documents. We all love them. One external cascading style sheet easily referenced by any web page on your site. All of your neatly-formatted rules contained in one place controlling the appearance of your kick-ass design. You handle browser differences and deficiencies with ease. You give your users content-rich printable pages. You might even have a sweet liquid layout allowing users to pick their favorite design. What more could one ask for? Oh, well if you have ever tried to send an (X)HTML email from your web apps, you and I both have a lot more to ask for.

If you have ever tried to send an (X)HTML email from your web apps, you and I both have a lot more to ask for.

I’m currently writing an application for a client of mine that’s rich in user interaction. In part, users can create accounts, verify email addresses, forget passwords, and more of the standard account-related functions. Needless to say, without any unnecessary overkill, we will be sending a good amount of emails to my client’s user base. I could have easily opted to send text-only messages, but the requirement included displaying a logo, bolding text, and other graphical presentations otherwise not available in text-only. So, without much hesitation, I charged ahead. Whip up some clean (and strict) XHTML, use loads of my already-fine-tuned CSS rules, pump in some content and we’re off!

Wrong. And this was just the beginning.

I use my Gmail account for testing — it’s convenient because all the messages get lumped into one conversation for easy review, not to mention the huge disk space and (my favorite) delete button closely within reach. But for all of Gmail’s successes, it sure wreaked havoc on my nicely-formatted XHTML messages. Evidently, Gmail strips every shred of code out of your email, and rebuilds it in its entirety before spitting it back into it’s wonderfully successful conversation view. Those unique div, span and other IDs? Gone. The short and sweet CSS rules? Gone, and definitely not working. Hell, even my one-line footer wrapped in a small tag didn’t render properly. I now know why I can’t read my itinerary confirmations from the airlines in Gmail.

To make sure I wasn’t out of my mind, I changed my testing email address to an account I manage with Outlook on Windows and Mail on the Mac. Naturally, the message came through looking as perfect as I could have ever imagined. I repeated this process with Mozilla’s Thunderbird and then webmail at Yahoo!, Hotmail, and AOL — all succeeded, but in different ways. Microsoft’s widely-used Outlook client performed the best (same goes for Outlook Web Access), followed closely by OS X’s Mail. Neither re-wrote my code. Yahoo! did better than Hotmail, but Hotmail’s new interface liked the HTML and CSS hybrid a little more than the old but it still wasn’t perfect.

I am fighting an in-browser application war! Here we have browser-based applications developed by the world’s largest software manufacturers performing the same basic functions displaying standard XHTML and CSS content from the same source — and it just doesn’t work. Grrr. In the end, it’s Gmail that is causing the biggest headaches.

Yesterday, I finished restructuring the code following tips I read about on this highly-useful Interweb (I love that old Verizon DSL commercial). Here are a few that helped me get going again:

• Don’t put anything in the head of your email template.
• Forget the love you have for your fine-tuned CSS document; there’s no hope of using it (as an externally linked file). You’ll have to drop all your classes and ids replacing them with hideous inline styles. If your email’s recipients use Gmail, you’ll need to do this one.
• If all else fails, especially with AOL, use a table to position your goodies. I can’t believe I typed that, but when it comes to this and saving time, it works.
• Have patience. I nearly tossed my lappie out the window on more than one occasion.

As of yesterday, my client’s customers are ready to receive fancy-schmancy emails. No matter which mail client, web-based or desktop, Mac or Windows, they’ll all see the same content — as it was intended by this designer. Now that it’s done and I’m filling out my time sheet, I find myself having a hard time justifying the large chunks of time spent formatting arbitrary (yet critical) emails when there’s plenty of other work that needs doing. It seems funny to me but after all these messages, like them or not, are part of your app and, more importantly, your client’s outward-facing marketing.

This entry was posted on Thursday, November 30th, 2006 at 9 am and is filed under applications, browsers, code, css, design, mac, standards, windows, work.