Coding an email template from scratch

Monday, November 23, 2015

email technology
Technology is supposed to grow exponentially, that is unless you’re talking about Email. Coding an email is like riding the Tardis back to 1995. What makes coding emails such a retro adventure? Unlike coding a website, with emails there’s little to no separation of concerns between HTML and CSS. Instead of divs you nest tables inside tables, and elements can only be assigned one class. It’s a mess. There are some golden rules here and there, but overall there is no “standard”. You have to forget everything you know about web development and get with the program.

"If HTML and CSS had an incestuous relationship, email HTML would be the offspring."

The reason why coding an email is so different from coding a website is because there are way too many cooks in the email kitchen. Checkout the diagram below to see all the different ways email code can be handled.
Image courtesy of
    Email Service Providers all handle email differently, each one with its own set of quirks. Examples
    • Yahoo requires a “yahoo” tag in the body.
    • Apple mail does not support “max-width” property.
    • Outlook will automatically stack your tables if there isn't at least 25px to spare on any given row.

    On top of that, there are golden rules to keep in mind, including:
    • If an attribute exists in HTML, use that instead of CSS.
    • Whenever you use CSS rules in the head of your document, you must use a tool to bring it all inline at the end of the process. (MailChimp does this for you). 
    • Do not shortcode. If you want to set the font size, weight, and line height you need to use font-size, font-weight, and line-height as separate style properties.
    • Hardcode image sizes. Do not use percentages. 
    • No javascript. No flash. 
    This past Saturday I decided to take on the challenge and code a responsive email template from scratch with the purpose of saving a boilerplate that I can reuse in the future to save time.  There were two aspects that proved more difficult than the rest, and by a lot: nested tables and edge cases.

    Nested Tables. 
    At first the idea of using nested tables seemed very simple and straightforward, but in practice it makes for really ugly, messy code. It is very easy to get confused, and accidentally delete tags or elements when moving things around. The constant attention to this detail made for a much slower development. 

    Too many edge cases
    There are tons of Email Service Providers, each one treating email code differently, and there are tons of devices, all rendering that data differently as well. To solve this problem it is necessary for constant testing  across all providers and devices during development. Doing this manually is a ridiculous waste of time. Fortunately there are services like Litmus that can do this for you. Unfortunately they are expensive (if you know of a better solution, please share in the comments!). However, chances are that if you are coding emails from scratch you probably work for someone that can pay for the service. 

    Final Product
    Take a look at my final product (resize window to see it's responsiveness in action). Look under the hood for the source code. If you find any quirks or bugs, or have any tips to code email templates please share in the comments. 

    Are you up to the challenge? Here are some helpful resources to get you started:

    Finally, for design inspiration check out my beautifully curated Pinterest board:

    Happy coding! 

    You Might Also Like


    1. Great post! It would be so much better if there only one pattern to code (like HTML5) in which every email provider should follow, our life as developers work so much simpler.
      I keep reusing the same template to save the time LOL

      Btw, it always a relief to find woman who knows how to code, go girl! :)