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.
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.
Cerberus: “A few simple, but solid patterns for responsive HTML emails.”
MailChimp has Email Blueprints on GitHub. They haven’t been touched in 3 years though, and I’m not sure if that means they are missing any new/big/important techniques in HTML email development or not.
If you cough up your email to 99 designs, it looks like they will send you some.
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.
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.
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.