Email development can be a tricky beast. I’ve known this for some time now, yet somehow even after I’ve designed and built many sets of email templates while working at SendGrid, it still amazes me how complex and confusing it can be to achieve what seems fairly straightforward.
Part of this complexity has to do with the multitude of email clients and browsers that are out there being used. Each of these clients has a wide variety of support for features that developers take for granted when it comes to modern HTML and CSS.
Recently, I set a goal to build a set of email templates that focused on common use-cases for transactional email. The idea was to help SendGrid customers jump-start the account set-up process with a set of templates they could plug-in and easily customize for their brand. As I worked through these templates, it was inevitable that I was going to come across some things that just make you scratch your head and say, “why?!?”.
The “bulletproof” button is one component that email developers should be familiar with using. It’s the standard way to build buttons in email templates, using tables, that works responsively. One would expect to paste the code, adjust the styling to match your design, and move on. However, as I was testing one of my new templates, I came across an odd issue in Outlook.
The buttons would not display correctly because I had given the anchor href a placeholder hash:
It turns out that Outlook strips out anchors if they don’t have a valid URL. Had we given this anchor’s href a value of https://sendgrid.com, our button would have rendered correctly in Outlook. It’s a very small issue, but a perfect example of a very small quirk that can wreak havoc on your template and your mind when testing.
If you’ve ever used an iPhone, you’ve probably noticed that iOS is pretty good at creating links out of telephone numbers and addresses, to make it easier to call someone or open an address in Maps. This can be super helpful, but say you’re crafting an email template that uses blue for a background color and you want to include your company phone number or address in that section?
Now, these auto-generated links blend into the background and aren’t helpful to your recipients. There have been several attempts at solutions that weren’t 100% bulletproof. Thanks to the fine folks over at Bring Dialog, we now have a solid solution:
We should be able to use nicer typography in our email templates, other than the standard set of 20-something fonts that are included on every computer. I’m not hating on Helvetica or Arial…but, often they just don’t fit your brand or company personality. Good news, you can use Google Fonts in your email designs, with various support (sorry Outlook users).
As I experimented with this for our transactional templates, the community consensus was that the .woff extension provided the best cross-client support. The trick here is that Google Fonts doesn’t exactly let you specify which file type you want when consuming their fonts. There is, however a sneaky shortcut to get the URL to the WOFF file.
If I open that URL in Chrome, I can see the @font-face declaration for the font. However, Google has sent us back WOFF2 versions. This is expected since we’re using a modern browser that supports the WOFF2 format.
This isn’t helpful for our use-case of email development. We need the URLs to the WOFF files. Opening the URL in an older browser is the key to getting back the font format that we’re looking to grab. In my case, I used BrowserStack to access this URL via Internet Explorer 11. You can use a virtual machine, or a Windows device too… it just has to be an older browser that doesn’t support the WOFF2 format.
Your email template looks great and works in every client you’ve tested. However, in Android 4.4, your email is no longer centered in the device. It turns out, Android 4.4 adds an HTML wrapper with some inline styles to your email that can break the centering of your main content. We can pretty easily override this in the styles for our templates:
Some devices have set a minimum font size to maintain legibility, however, this isn’t always ideal when designing an email template. The device’s minimum font size could potentially break your layout or cause display issues that you didn’t intend. Thankfully, it’s fairly straightforward to override this behavior in iOS and Windows Mobile with some styles in the <head> of your template:
These are just a few of the issues I faced as I worked through building a set of transactional templates our customers could use and modify. Hopefully, these tips will help you avoid some of the headaches associated with email development.
There are, of course, many other bumps along the road to building a set of templates that work well across clients and browsers. Make sure you are testing your code and not making large changes between checks—it can become very difficult to track down why something is broken when multiple lines of code have changed.
Be patient and leverage the knowledge of fellow email developers and best practices to help you get off to a great start. Finally, be specific when searching for issues you are having with your templates. It’s very likely that someone else has already run into that issue and found a solution or workaround. And if you'd like to learn more about email development and design best practices, check out my other blogs that cover style guides and design best practice tips.
