I had the chance to give a quick talk at HubSpot on the stuff I’ve been doing with email (like programmatically changing email content after it’s been sent). In order to do email justice, I’ve broken it into two parts. Part one is about how to properly design for email. Check back next week for part two: How We’re Hacking Email at HubSpot.
Problems with Email Design
There are lots of constantly changing variables.
Creating a beautiful, stable email is arguably more difficult than designing the equivalent web page. You have multiple types of desktop email clients which each have their own quirks and restrictions. There are also an ever-increasing number of web-based clients, and each can be viewed in any of the 7+ major web browsers. In total, you end up coding for over 65 different environments.
Your code is augmented or overridden.
There are multiple places along the way where your content can get parsed and mutated. Once you hit the send button, it’s out of your hands.
You’re only armed with HTML and CSS.
If you want to do something really clever or unique, start wracking your brain for ways to do it with CSS2. Even then, there are only a handful of things in CSS that are fully supported by all of the clients.
- table-layout (no idea what this does)
- most of the typography stuff
This means that even basic CSS properties that we took for granted (background, display, position, etc.) aren’t fully supported. When you’re designing an email, make sure to keep that in mind and know when to take a risk and when to play it safe.
How to Approach Email
You should approach email like a worthy advisary. Understand the playing field and do your best to level it.
Know your browser distribution.
Especially before you try to do something fancy. Some browsers are more restrictive than others, and it’d be a shame to invest a lot of time in a specific email technique only to find that a majority of your customers use clients that don’t support that feature.
At HubSpot, almost half of our customers use some version of Outlook, but a decent amount of them use Apple Mail and iOS. Because of that, we have a decent amount of room to do cool things with email.
Avoid inline important flags (!important).
Inline important flags have the highest level of authority in CSS. If you’re looking to override something in a CSS block later on, don’t use an inline important flag. In a general way, understanding the order in which CSS declarations are inherited is pretty useful knowledge to have.
Lastly, be mindful of file size limits.
Gmail and some mobile devices truncate messages that are too large. This usually isn’t a big deal, but make sure to test for it when you can. Emails that are particularly image-heavy are going to be very slow to load on a phone over a 3G (or less) network, and your customers might not be willing to do that.
Some Basic Solutions
Code like it’s 1998.
Or whenever the internet was invented. I think it was sometime before I was born.
Use tables, inline styles, and avoid fancy CSS tricks like floating elements.
Be painfully explicit about all of the CSS rules that you set or unset, and remember that you may need to do things to override the existing environment. For instance, <h3> tags are green in Hotmail by default, so you need to explicitly set a CSS rule on those elements in order to get the color you want.
Some Quirks About Tables
Tables are awesome for email, but there’s a reason we stopped using them for websites a long time ago: they’re rigid and suck. Here are a few techniques to make them suck less.
Style your <td> tags, not <tr> tags.
Generally, <tr> tags don’t have many useful CSS attributes, and they’re certainly not very good at handling margins, padding and borders. Save yourself some trouble and don’t bother setting any CSS rules on these elements.
While you’re at it, don’t worry about the <thead>, <tbody> and <tfoot> tags either.
Use divs for spacing.
Margin and padding work just fine on <td> tags, but it can get annoying to update your margin/padding styles when you have a row with 10 columns. Don’t fall prey to using the <tr> though! Instead, wrap all of your columns in a <div>.
Here are a few interesting things I’ve picked up since working in email.
Crashing Outlook with images.
I’m not exactly sure why, but Outlook requires images to have a protocol (http or https) in the “src” attribute. So if you do something like:
<img src="//www.example.com/image.jpg" />
Outlook will freak out, seize up and ultimately crash.
Hotmail and the color green.
Any <h2> tag and above will automatically be turned a Kermit-the-Frog-green if you don’t use an !important flag.
Outlook 2007+ use Microsoft Word.
Of all the weird things I’ve seen in email, this is the one thing that baffles me the most. Versions of Outlook prior to Outlook 2007 used Internet Explorer to render emails. This means that if you were designing an email in 2005 and it looked good in Internet Explorer, there was a very very good chance it’d look exactly the same in Outlook.
But some time before the launch of Outlook 2007, the team there decided to ditch the browser that their colleagues had built and use the half-baked rendering engine from Microsoft Word. They even wrote up a blog article explaining their decision to continue using it.
Check back next week for part two: How We’re Hacking Email at HubSpot. If you understand the basics of email and want to push the boundaries, I highly recommend reading the next part.