When building a web page, one must always keep in mind the differences between the way browsers implement (or don’t implement) web standards.
When building emails, this is much, much worse. For starters, there are no specific standards regarding what should and shouldn’t be allowed to display in an email, and client support varies very widely. There are also many people using various webmail clients, and these people don’t all use the same browser.
Many of the practices frowned upon in web design are a necessary evil when it comes to emails. For example, using tables (and nested tables – *shudder*) to determine layout. Positioning styles are not widely supported in some of the major email clients (including Outlook 2007/2010). So if you want a consistent layout, take a trip to 1995 and build it with tables. Another major rule-breaker is inline styles instead of style sheets. Most notably, Gmail doesn’t allow any <style> tags or external style sheets of any kind. That means if you want Gmail users to see your styles, they all have to be style=”” attributes. I know, it’s terrible, right? You’d expect more from Google.
Unfortunately email compatibility often even competes with conventional web development wisdom in its core philosophy. While generally web developers will tell you to build with the most-compatible browsers in mind and use various methods to “degrade gracefully” for the less-fortunate, often in email there’s little choice beyond designing for the lowest common denominator. Since there are very few options for fallbacks, unlike traditional CSS, one often has to find a method that works for everyone and leave it at that, even if it’s not as nice as we’d like. One exception can be background images. Some clients don’t support them, but lots do. You can use them, but you should have a background color as a fallback.
There are also some similarities to keep in mind. Though often layout, along with lack of web-font ability, requires some text to be rendered as images, try to limit non-live text as much as possible. For web design, this is largely done for SEO purposes, for email, it’s mainly to prevent the user’s client from labeling the message spam, as well as allowing the user to read the message without clicking the “Images have been hidden” button that’s common among email clients. Additionally, for both applications, live text simply looks better.
It’s important to find out what clients support what styling, and determine your code accordingly. And of course, test your email in as many clients as possible before sending it out. Campaign Monitor has a great guide to CSS support in email that covers 24 of the most popular clients. They also have useful tips and guidelines on building compatible emails, and lots of free templates. Thanks for reading. Don’t forget to share this post using the social media buttons.
