Little did I know that in my first week as a fulltime Sparkboxer, I would be thrown into the trenches of styling emails circa 1999. I mean no disrespect to those devoting their time and careers to styling emails, but I was extremely critical of email design when I first started out. I had read and heard a lot about how finicky and stubborn email clients were. I had also grown accustomed to how much of a catalyst for complaint table styling was among the web community and how grateful most people were that the web had progressed beyond it. What particularly stuck with me and defined my somewhat prejudicial opinion of table styling was Eric Meyer’s comment that table styling was a “rectangular prison” that has defined the web for close to two decades.
Where to Start
When I started to seriously pursue a career in the web, table styling was well beyond the vocabulary of most web designers. As a result of this, I barely even knew where to begin. There are a plethora of resources available on email templating, but after a good amount of searching, I ended up going with Dan Denney’s Emayll templates.
Emayll is an email templating tool written in Haml and built using jekyll. The layout of Emayll is very much like any other jekyll project, with a few exceptions. An obvious one is that Emayll uses Haml instead of html. Personally, I’m not a huge fan of terse html, but in the case of email styling where tables are nested within tables—and then some—Haml is a great way to keep your code organized.
Regardless of whether you are familiar with jekyll or not, Emayll is a breeze to set up and get started in as little time as possible. Setup simply involves installing jekyll (if you don’t already have it); just run: gem install jekyll, then clone or fork Dan’s github repo with git clone git@github.com:dandenney/emayll.git and run the jekyll server with jekyll serve.
To add new templates to Emayll, you must first create a folder within the home directory, i.e. _marketing. You would then append the new email to the _config.yml file:
marketing:
output: true
and add the new email to the index.html file:
{% for post in site.marketing %}
{{ post.title }}
{{ post.categories }}
{{ post.status }}
{{ post.service }}
{{ post.purpose }}
{% endfor %}
In order for the new email to show up in the global index page, you have to add meta details about each email to the yaml front matter—the content between the triple-dashed lines at the start of the Haml file.
---
layout: email
title: "A Marketing Email"
categories: marketing
service: "none"
status: "inactive"
purpose: "A base starter file for marketing emails."
---
If you end up having to write email templates of the same category as another, you can just add the Haml file for that email to the existing directory without having to update the _config.yml file. Another really nice feature of using jekyll is the ability to store reusable snippets of code/partials in the _includes folder and add them into your templates using liquid tags: {% include footer.haml %}.
Testing (and Hacking) for email Client Compatibility
Plain, simple table styling is one thing; doing it for broad compatibility across email clients is a whole other beast. I do most of my email testing via Litmus and have slowly over time uncovered some of what makes the various email clients unique in their rendering of html emails. For instance, the only way to get background images in a table cell to load in Outlook 2007 and up is to use VML, which looks something like this: https://gist.github.com/shortdiv/16d16d278bb921d0bf8f.
Campaign Monitor has a great article that explains this concept really well. For those of you with less patience to write out your own VML script, you can also use https://backgrounds.cm/, which is a tool by Campaign Monitor that outputs VML for you.
The VML script obviously breaks the elegance of Haml, but considering that the majority of email clients are adamant to progress and standardize email technology, we aren’t left with much of a choice.
Future Steps
If time is on your side, I would definitely recommend building a more robust workflow for email template styling. Premailer is a great tool to integrate into your build system as it removes the cumbersome process of inlining CSS by hand and automagically converts an external stylesheet into inline style attributes. Adding Premailer to your workflow is as easy as adding the Premailer gem to your Gemfile and running bundle install.
require ‘premailer’If Grunt is your task runner of choice, there is a Grunt wrapper for Premailer available via npm.
Alternatively, if you’re looking for something a little simpler, both Mailchimp and Ink (Zurb’s email templating framework) provide inliner tools that allow you to paste html content right into a text box and make your code email friendly at the click of a button.
Keep Fighting the Good Fight
Considering that I am at the start of my career as a fully fledged developer, learning what used to be the bedrock of the web world was extremely humbling and served as a timely reminder that I stood on the shoulders of giants. There’s much more to email than meets the eye. In my short stay in email land, I learned a lot about email styling and gained so much respect and appreciation for all those fighting against the rigid limitations of email clients.
