Last week’s ShopTalk Show was all about HTML Email. It’s such a fascinating subject, as technically it is front-end web development, but it almost feels like a bizarro alternate universe.

We have dozens of browsers to worry about, they have hundreds of clients to consider. We worry about whether fancy new APIs are supported, they worry about whether padding is supported. We have grid layout, they have…. grid layout?!

It’s tempting to make the joke: “It’s coding like it’s 1999!”, but as we talk about in this episode, that’s not really true.

Aside from all that, another thing I thing fascinating are all the tools involved. Lemme think this out.

Creation Tools: Bare Metal

You can create an email with just HTML. I’m sure quite a lot of HTML email is created this way. Open code editor, create HTML email, send HTML email. I know I’m tempted by this and go this route a lot, especially when creating an important one-off email.

Check out Really Good Emails on CodePen, where they have archived loads of the full HTML of sent email campaigns.

The builder tool in Litmus is also a bare metal editor. You see and edit the entire HTML document.

Creation Tools: HTML Templates

It’s still creating by hand and hand-authoring HTML, but you can reach for HTML email templates. This is probably a very good route for most us, because of how tricky HTML email can be to get right. Fortunately, a lot of the hard work of figuring out nice and simple email templates with functional layout and type has already been done.

Creation Tools: Abstracted Templates

Creating an email by directly working with one big giant gnarly piece of HTML is certainly possible, but front-end developers hardly ever work that way. One of the first abstractions we always reach for is abstracting HTML into parts. You can do that with email.

You could use your own server-side partials to break up the HTML into parts, so that making new emails can re-use those parts and they are quicker to build and easier to maintain.

Dan Denney has a system called eMMail that uses Middleman, Haml, and Sass to abstract the emails into manageable parts.

Lee Monroe has a Grunt Email Design Workflow which is Handlebars/Assemble and Sass to piece emails together.

Foundation Emails uses an abstracted HTML language called Inky which compiles into HTML ready for email.

MJML is also a an abstracted HTML language designed to be preprocessed into HTML for email.

UI Builder and Sending Tools

Rather than touching code at all, you could design and write an email directly through a tool built for that. These choices are probably pretty obvious to most folks, as there is huge demand for this. Rightly so! Tools like these let you get right to writing and designing the email without getting distracted by tools.

It’s just not always possible to use tools like this for all the emails you send. They are usually cost prohibitive for really giant email lists, and not really built for transactional email.

These tools tend to tie together the visual building of the email along with sending and analytics. Everything in one.

Sendwithus is a little different. It is built for transactional email, and gives you a system for building and templating emails, but doesn’t send them directly itself (despite the name). You bring-your-own email sending service. Speaking of which…

Sending Tools: APIs

These services actually send the email for you. You hit their API with the email itself, the subject line, the recipients, and whatever else they need and it sends the email. Here’s a non-comprehensive list:

Analytics is usually a feature that comes with these tools that do the sending. That’s true of these email APIs along with the build-and-send apps.

Inlining CSS tools

I always assumed this was absolutely 100% required for HTML emails, but it isn’t really. Most email clients support a <style> block in the <head> . That means you can ship CSS without having to inline it. Even when that is supported though, you need to think about which features are supported. Like just because a style block is supported, it doesn’t mean border-radius necessarily.

Email support chart from Campaign Monitor.

Even that red mark above is out of date, as Gmail does support style blocks now. So inlining CSS might be going away ultimately, but I imagine there are some email clients that still need it, and if it’s part of a build process anyway, I guess it can’t hurt.

Copy and paste in-browser tools:

Programmatic tools:

Testing Tools