Email Development Newsletter
{ Issue #3 - Workflow Optimization, Behind the Scenes, and Bugs! }

Like the previous issue, this one was nearly done weeks ago. But like coding, editing my writing is the last 20% but takes as much time as the first 80%. Hopefully I will find a rhythm to write and send these newsletters. In the meantime, I hope you appreciate the extra effort.

Did you noticed I screwed up last issue? Every newsletter should come from "Email Development Newsletter" and the [email protected] address, not me personally. Lesson learned: don't send out emails before heading to the airport ;)

Issue #3

Sneak peek: My Email Workflow
Behind the Scenes: Email Layout Calculator Selector Bug
Yahoo Style Bug

But before we begin, do you need any extra email development help this holiday season? I had a project fall through so I have a some extra time in December. If you need a one-off email fast (1-2 business days), get in touch. I have some time and am always up for a challenge :)

Greetings from Munich

I. Sneak peek: My Email Workflow
This past week I finally finished a blog article about optimizing my email development workflow with ruby. It will be published on Monday, 7 December. But as a subscriber, you can read it first.

I wanted to align my web development and email development workflows as much as possible. For me, this meant leveraging CSS stylesheets (reusable components FTW) and ensuring they would not be mangled in the inlining process - where most bugs occur.
My Email Workflow
Email Development is tedious… how can we speed it up?
I also needed advanced email management. I tend to work on many emails for a single client, not just a single newsletter. Therefore I also needed a reliable way to reliably share and separate CSS. I couldn't find a solution. But I am also a ruby developer, so I built my own.

Read: Optimize Your Email Development Workflow →

From the command line, I can easily add/remove emails based on templates, start/stop a development server, upload images to S3, send test emails, and most importantly: compile HTML and inline CSS.

But I am most proud of being able to inline snippets of code and preserve programming logic. Coding Newsletters are easy one-offs. Architecting an email template framework is hard. That's why I created this.

Enjoy first access to the article and send feedback and questions. I love hearing from my readers :)
II. Behind the Scenes: Email Layout Calculator
As a developer, I love insights into how products are built. I want to share with your how I built the Email Layout Calculator. This tool helps you generate the HTML markup including Outlook wrapper tables to create a responsive grid that also works in Gmail on Android.
Email Layout Calculator
The original version was built in an afternoon as a proof of concept to accompany the A Gmail first Strategy for Responsive Emails blog article. But as I started using it more myself, I wanted to improve the UI.

I updated the calculator on 28 October and it now generates a complete template with all HTML and CSS code you need for the basic layout. It's still up to you to fill the columns with content. If you're curious how the logic works, see:

View HTML and CSS template →

Programming Logic Walkthrough

Feel free to skip this section, which goes through the JavaScript and math used to calculate the column widths and gutters:
var totalContent = container*1 - (gutter*1 * (columns*1 + 1);
var colContent   = totalContent/columns;
LazyDev Protip: in JavaScript you can use *1 on any String to typecast it to an Integer. Shorter than parseInt() :)

Once I had the widths, I stored each column in its own model:
var Column = function(index, content, gutter) {
  this.index   = index;
  this.content = content;
  this.gutter  = gutter;
  return this;

Column.prototype.calculate = function() {
  this.isFirst = (this.index === 0);
  this.isLast  = (this.index == -1);

  this.gutterLeft  = (this.isFirst) ? this.gutter : this.gutter/2;
  this.gutterRight = (this.isLast) ? this.gutter : this.gutter/2; = this.gutterLeft + this.content + this.gutterRight;

  return this;
This moved all calculations from my templates (view logic) into the Column model, which is easer to test. That's pretty much it. The rest of the JavaScript is mostly for the UI to render the diagrams and code as you adjust the forms.

The Calculator is not finished. In the next iterations I need to move more methods into the model and add tests to verify my maths.

This tool was created with Backbone and Handlebars because it's what I know. You can implement the maths above in the framework of your choice.

III. Selector Bug
Once I was debugging an email and noticed my headers and footers were off. They were not broken, just not pixel perfect. Usually the grid was off. But why did it work fine in other clients?

Viewing the source code in, I noticed that my table cell looked like this:
<td class="header" … >
But most other selectors have a ecx prefix like this:
<td class="ecxfoo" … >
And because the included CSS style selectors are prefixed, the .ExternalClass #ecxheader selector is not found. To solve my bug, I simply renamed my selectors, for example: .headr.

But what other selectors are ignored? I created a test email to find out:
Outlook cannot parse some selectors
Testing CSS Selector Patterns
I tested my most common selectors to see if I could find a pattern. I discovered these selectors do not work in


IV. You too, Yahoo?
Of course I tested various email clients and noticed Yahoo didn't support my selectors either. But it should! So I sent myself a test email, checked the source code, and discovered my !importants had disappeared.

Then I tried some code adjustments and stumbled on this:
Yahoo: Yellow on Green is 50/50
Notice anything odd?
It turns out Yahoo does not like the space before !important for color and background-color properties.

Totally random, right? I only discovered this problem for these 2 properties, but not for padding, for example. To get my selector test email working in all clients I used:
  .selectors {
    color: #ffffff!important;
    color: #ffffff !important;
    background-color: #1AB75D!important;
    background-color: #1AB75D !important;
Other clients require the space before !important, so I have it twice. Alas, redundant code is the email developer's life.

Do you know any strange bugs?
Let me know and we can share them with everyone :)