Author: Patricia Johnson
Part 1: The Code That Time Forgot
Like me, you probably expect that html code is going to display virtually the same in every browser, with a few known exceptions. There are small foibles in rendering between the assorted web browsers, but with every update, those differences become fewer and fewer, and the CSS “hacks” for these issues are well-known and widely used.
Until the first time you’re assigned to program an HTML email. Oh, it looks easy enough, and often it doesn’t even have to be responsive, so you quickly code the email, checking in all the browsers for inconsistencies, and then send it off the test email. And then it explodes in your face. What was beautiful HTML code in your web browser has arrived in your inbox looking like something straight out of Geocities, circa 1996. What happened?!
Email clients seem to have a free pass on W3C standards compliance and implementation
To some degree, every existing email client has varying, but never complete, W3C standards compliance in their html rendering engine. Some are pretty close (Apple and iOS) and some seem to be thumbing their nose at the W3C and making rude hand gestures at developers everywhere (Outlook 2011 uses IE as its html rendering engine, but every other version, including 2016, uses MS Word). Because of this, developers often flail about virtually, and sometimes actually, when coding their first emails. None of the things you can take for granted when coding a webpage seem to be true, when it comes to programming for email. And since there’s no way of knowing until after the fact which email client your recipient is using, you have to code your email for the least common denominator. Just pretend it’s 1999, and you should be fine.
First off, you can stop making that face.
There’s no getting around it. I know, if your web portfolio was written like this, you could expect not just to not get the job, but to perhaps be laughed out of the interviewer’s office, and maybe even hear some four-letter words for having wasted their time, on the way out. But this isn’t a webpage, it’s an email, so just grit your teeth and bear it.
Say goodbye to stylesheets
Due to potential security issues, emails will not allow you to reference an external stylesheet, no matter where you host it. And because Gmail does not support <style> tags, in either the head or body of an email, every bit of CSS you write for the desktop view must be an inline style.
Fortunately, there are several free tools available online to help with your inline style needs. Campaign Monitor’s CSS Inliner or Zurb’s Ink allow you to write a <style> tag in the head of your html document – when the time comes to deliver the email, you will copy and paste your code into their tool, which will then add the CSS not found inside media queries (more on responsive emails in a later post) to your html code as inline styles.
Just a tip – I would save the version for delivery out as a separate file. It makes it a lot easier to tweak your code, should you find any bugs (and you will) after that first test send.
Say Hello to Deprecated, Ugly, Tangled Code
While you can use modern HTML and CSS for much of your email, there are a few common elements you won’t want to use, either because it will make adding responsive code easier later if you don’t, or because it simply is not supported in one or more of the major email clients.
The first major difference is that divs won’t work for layout anymore. You must go back to using tables to create your grid. Don’t forget to add “cellspacing=’0’ cellpadding=’0’” to every <table> declaration, or Outlook and its incarnations (Hotmail, Outlook.com) are going to add a seemingly random amount of padding and space to your table elements, throwing your design off in a rather spectacular manner. You also want to declare your dimensions in the “td” tags, but not with css – use “width=x” and “height=x”, without “px” after the number. This both prevents box-model issues and makes it much easier to change the dimensions in your media queries, should you use them later.
And speaking of Outlook, it doesn’t recognize the “padding” property for p, div and a tags, so you’re going to have to use nested tables with padding added to the <td> tags for your white space needs. To make this an even bigger slap in the face, Outlook.com doesn’t support “margin” at all, so it’s more nested tables to the rescue. Outlook also doesn’t recognize images as block level elements by default, so every <img> must have “display: block” in its style tag, as well as “border=’0’” in its attributes if it’s part of a link, in order to get them to sit where you want them, and not have big blue borders.
“Float” is no longer an option, which is why you need tables for columns. If you need something to move to the left or right of something – for example, an image, placed to the right of a paragraph- you’ll need to use “align=’right’” in the image tag.
Thanks to Outlook (again), you will have to re-declare your font statements – font-family, color, font-size, line-height – every time you add another nested table – it will not inherit past a “table” tag. If you are using one of the inlining tools I linked to previously, you may want to add those declarations to the td, p and a elements, to be sure they are always correct. Otherwise Outlook will pretend you’ve never mentioned font styles, and will serve up times new roman, in black, at the default font-size for the recipients’ version of the client. Additionally, you need to declare font-size and color in every <h> element, now that Outlook.com wants to apply its own formatting to headlines. If you don’t want your h1 tags to be green (I’m not exaggerating – Outlook.com makes all h1 tags green by default), you need to specify what color they should be, even if the color is already declared elsewhere (for example, in the surrounding td tag).
Email Best Practices
Your email should be roughly 600px wide at its maximum resolution, responsive or not. This prevents side-scrolling in most desktop email clients, and also prevents too much white-space around the email in the reading pane.
Do use white space appropriately. Huge blocks of text are hard to read – remember to break up paragraphs with a little spacing in between, and have some padding between columns, if you used them.
Do use a web-safe font – you can’t call to a font server in an email, just like you can’t call out to an external style sheet. Georgia and Verdana are easy on the eyes, with Arial and Helvetica a close second. Always add a fallback to your font-family declarations – “Verdana, Arial, Helvetica, Sans-Serif” will make sure no one accidentally gets Times New Roman, even if they don’t have Verdana, Arial or Helvetica. It will save the readers’ eyes, and your design aesthetics.
The only exception to the above rule is if you’re programming an email intended solely for internal corporate use, and the font in question is their corporate brand font – it’s safe to assume that everyone in the company will have that font installed on their work computer. Still provide the fallback fonts, because more than half those people are likely to open that email on a personal mobile device, which may not be able to access that font, at one time or another.
Keep font sizes at 12px or larger if at all possible. Not only are smaller fonts hard to read on a mobile device, but the Apple email clients will “fix that” for you by blowing up tiny fonts to a larger, more mobile-friendly size – but will not adjust the line-height, so your text may be squished or even have overlapping lines.
Optimize your images for file size, and if you’re the designer, try to use no more than 6 per email. Images increase load time on emails, and studies have shown that even increasing load time by a few seconds can dramatically increase the rate of deleting said email before it ever opens, especially on mobile devices. Gmail and some of the other email clients count the number of images in your email, and may flag your email as potential spam if it has more than half a dozen images. Always supply alt tags for your images, for use by screen readers, and hard code the dimensions using the width and height attributes of the img tag, so your layout isn’t askew if the email loads with images disabled by default. Those descriptive alt tags will help get your message across as you intended it, even if the viewer never downloads the images. Tinypng.org offers a free, web-based png and jpeg compression tool that can cut your file sizes by an average of 30 – 75% or more, with no visible loss of quality.
Remember that unless you’re creating an OFT (Outlook Format Template) or EML file only as the deliverable, your images are not embedded in your file, and the images must be hosted online somewhere, with absolute paths in the html to reference them.
Email testing services like Email On Acid or Litmus will save you time and prevent frustration-induced baldness. These services allow you to send a test email to a single email address, upload a zipped file with your html and images, or copy and paste your html code (or all 3), and then shows you a screenshot of how your email looks on arrival in almost every email client conceivable. This is especially valuable if you’re programming responsive emails, but it is always good to see how your email holds up on Apple Mail vs an Android phone vs Gmail in Chrome vs Outlook 2011, whether it is responsive or not. You can quickly check and recheck for any client specific errors in your email with these services, so that the email files you deliver are bulletproof, whatever their format – without having to own an extensive testing lab of computers.
There are numerous quality resources online for learning more about the pitfalls of programming emails. The blogs at Campaign Monitor, EmailOnAcid, Litmus, and Mail Chimp are full of extremely helpful information when it comes to troubleshooting your particular email issue.
Author: Patricia Johnson