Clients love HTML email.
Done correctly, it looks slick as all get-out; it prompts users to action; it drives traffic for a special promotion; presents an exciting, professional image; lifts you aloft and floats you to heaven. All with higher response/action rates than plain-text email messages.
However, as every web developer knows, doing it well is a nightmare. Design/layout is the easy part; the sticky parts are numerous. Different email clients render HTML email with, shall we say, somewhat uneven support for web standards that are increasingly respected in modern browsers. Further, many email clients come configured with default settings to that disable images, adding another factor to consider. Finally – well, not finally, but the list of issues feels effectively endless – HTML email is often used by spammers, so there are more complicated considerations associated to ensuring that your messages do not get incorrectly tagged as spam.
There is a growing body of best-practices that has slowly developed for HTML email. These practices are not “best” in the sense that they represent elegant, flexible coding philosophies (like DRY, OO, for example) or minimal load times or optimized development practices. Rather, these ideas are considered best-practices, IMHO, merely in the sense that they “work”: they offer the best chance that your message will be received by the intended recipient and be reasonably well-rendered when he views it.
These best-practices include foregoing all the techniques we learned for creating semantic markup that cleanly separates content from presentation using CSS; instead, we are told to use tables for layout. We should no longer refer to styles in an external style sheet since most email clients – especially web-based ones like Hotmail, Yahoo, and Gmail – will strip them out; rather, we should use inline styling, repeating style information on nearly every element that needs it, inducing bloat and making modifications a tedious search-and-replace activity rather than a simple change in a single style declaration.
Other best-practice resources often conclude by pointing to Campaign Monitor or MailChimp and advising readers to download their free templates and use them as directly or as a starting point for editing or even as a guide to these best-practices. Both sites claim that their templates have been tested to render fine in all major clients.
Now, Campaign Monitor is great. These guys are founders of the Email Standards Project. I totally support the idea that someone should be pushing email clients towards better support of web standards, especially CSS support. The first step in that direction is measuring and evaluating the current support. And their chart of CSS support in major mail clients is a tremendous resource.
But the first template I downloaded from CampaignMonitor violates a bunch of these best practices right off the bat and fails to render correctly in Gmail. The template has nearly all of its styling inside a <style> tag inside the page’s <head> section. CampaignMonitor’s own CSS support guide referenced above notes that such an approach will not work with Gmail, yet their template includes it and claims to render fine.
Gotta tell ya, I’m a bit disappointed.