I remember the late 90’s as an era of both pop, and if you lived in my neighborhood, reggae. It was an age where the closest thing to anime on American Television was Sailor Moon, and N64 was still new. Not every household had a computer, and AOL was the best thing since sliced bread.
One thing that might not have been so memorable, however, is the way HTML and CSS were written when compared to some of the ease and limitless options we have today. HTML5, CSS3, JQuery – so many shiny bells and whistles, oh boy! And if you’re like me, and there’s a way of writing code that will not only make things visually pleasing, but save time and provide less hassle on the front-end, then you’re going to make good use of those bells and whistles, right?
Well, making an HTML email may seem like it goes against natural instinct. Not only does it have to be written as if you’re back in the 90’s, but testing them is not the same as testing a website in multiple browsers.
It’s taken me some time to get accustomed to making HTML emails. While design as well as whether or not these emails are intended for mobile, or if they’re going to be integrated into something else like Campaign Monitor or Mail Chimp, may change how the email is made, I’ve come up with some general practices that help to ensure that the email works in all, if not most, email clients.
- Tables: Okay, okay, I’ll confess, I really hate tables. Nothing reminds me more of those bad Dreamweaver sites with blinking gifs and blinding colors more than a table does – however, even a table has its uses in today’s modern world. All Emails should still made with a table, and it’s a good idea to look at your design and plan your table(s) before you dig into code. Once you start making your table(s), it helps to tack on border-collapse, cellpadding, and cellspacing at zero. I keep border at one just so I can see where things are as I build, before I set that at zero as well. TIP: There should be no floats in HTML emails. So be sure to take that into account when you plan your table, taking advantage of the columns and cells to place things next to one another.
- Css styles in the header : You probably shouldn’t unless it’s absolutely necessary or it’s a fallback. I’ve used this at one time to cancel out the automatic -webkit-text-size-adjust on iphones/ipads because it was breaking the design. Now, take in mind that a lot of modern email clients are catching up on trends, so some are reading CSS without a problem. But if your goal is to accommodate for the widest range possible, for your audience whether they’re checking email on Gmail or on an older version of Outlook, the more styles you can write inline, the better. Also, no divs. Just p tags, span tags, anchor tags, font tags and so on.
- Padding and Margins: Another one of those things that some email clients won’t have a problem with. However, just like browsers, email clients interpret margin and padding differently. Some will remove it completely. So to avoid your design from drastically changing from one email client to another, I’ve become accustom to this handy trick I learned here at Pixafy, and use a blank or empty gif or png file. Usually this file is just a 1×1 pixel image of transparent nothingness that I put together in Photoshop, and I place it between certain elements where I know spacing will stay the same – like the space between a logo on the top and it’s content underneath it. It will usually look something like this: <img src=”images/blank.gif” width=”600” height=”25”/> So rather than padding or margin at 25px, you have a blank image with that same height. TIP: Spacing will also keep consistent to the design more by adding a valign=”top” to your table TD’s.
- Font Tags: While testing emails I’ve made in the past, I’ve realized that email clients sometimes interpret links differently, mainly with color. So to try and restrict that as much as possible, not just with links but all text in general, I wrap text with font tags that contain the colors, nested inside of the anchor tag/paragraph tag etc. Just to be safe.
While I can’t guarantee that everything will be perfect and you won’t come across a few snags, these few practices have at least given me a head start and helped to narrow down problems during troubleshooting. Be sure to continuously test your email, in your browser as well as in a testing environment (we’re big fans of Litmus). I’ve also learned the hard way that Outlook on PCs and Macs don’t always render the same.
And even though you’re writing code like the 90’s with “Larger than life” playing in the background, remember that today we have Google. You’d be surprised at all the wondrous tips other web developers have shared to make email creation as painless as possible. Happy email making!
Do you have best practices for email carving/creation? Share in the comments or tweet us @Pixafy!
